MSCRM 2011: Trial period has expired al actualizar de Beta a RC

30 12 2010

Al intentar actualizar una organización de CRM 2011 Beta OnPremise a la nueva versión RC me apareció el siguiente error:

La instalación de la versión RC la realicé en un nuevo servidor, es decir, no desinstalé la versión Beta e instalé la RC sobre el mismo servidor. Tras consultar varios blogs encontré que la solución era editar la tabla ConfigSettings de la base de datos MSCRM_CONFIG (que restauré de una copia de seguridad de la versión Beta). En concreto los campos que he actualizado son:

InstallOn: La he modificado por a fecha actual
LicenseKey: He añadido el valor MQM2H-JYYRB-RRD6J-8WBBC-CVBD3
LicenseKeyV5: He añadido el valor MQM2H-JYYRB-RRD6J-8WBBC-CVBD3
LicenseKeyV5RTM: He añadido el valor MQM2H-JYYRB-RRD6J-8WBBC-CVBD3

El cambio lo he realizado sin cancelar la instalación por lo que, tras realizar los cambios, he utilizado la opción Retry y la instalación ha continuado sin problemas.





MSCRM 2011: Error al conectar PluginRegistation a CRM OnLine

20 12 2010

Intentando subir un plugin a la instancia de CRM OnLine me he encontrado con un error. Al iniciar el acceso me devolvía un error de tipo:

An unsecured or incorrectly secured fault was received from the other party

Tras dar muchas vueltas al tema, como siempre, he encontrado la solución en el link http://crmconsultancy.wordpress.com/feed/#pluginregistrationtool. En concreto la solución la he encontrado en el párrafo en el que explica que puedes tener problemas con el archivo LiveDevice.xml:

I have seen a few problems around this where the ‘An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.’ error is encountered after specifying your CRM 2011 details – the following step can work to resolve this problem:

Look into your User Profile directory (C:Users[your user account name] in Windows 7), browse to a folder titled ‘LiveDeviceID’ and delete the LiveDevice.xml file contained within this folder. This removes any cached credentials from your workstation which may be blocking the connection between the Plugin Registration Tool and the hosted CRM 2011 Service.

Efectivamente, he eliminado el archivo LiveDevice.xml (eliminado no renombrado y sobretodo, tras reiniciar el PluginRegistration) y he podido conectarme sin problemas a CRM OnLine.





MSCRM 2011: Actualizar la versión Beta a Release Candidate

17 12 2010

Hoy hemos recibido la noticia que ya estaba disponible la versión RC (Release Candidate) para MSCRM 2011 OnPremise. Rápidamente nos hemos puesto manos a la obra para descargar la nueva versión e intentar actualizar la máquina virtual que tenemos con la versión Beta. La primera acción que uno piensa que debe realizar ha sido ejecutar el setup de la versión RC pero, cual ha sido nuestra sorpresa al comprobar que esta acción nos devolvía un error informando que ya existía una versión no compatible con la versión RC.

A tenor del mensaje hemos pensado que faltaba algún rollup de la versión Beta, sin embargo, tras varias horas de desconcierto hemos encontrado una explicación, tan sólo existen dos posibilidades para actualizar la versión beta a la versión RC. Las dos posibilidades son:

A) Importar y Exportar

Esta opción consiste en exportar la base de datos de la versión beta a una nueva instalación con la versión RC e importar como una nueva organización. En el proceso de importación se convierte la base de datos de Beta a RC

B) Conectar a una organización existente

Esta opción consiste en desinstalar la versión Beta (sin eliminar la base de datos) e instalar la versión RC teniendo en cuenta de indicar que se conecte a una base de datos existente (la que teníamos en la versión beta). De este modo nos crea la nueva organización a partir de la conversión de la base de datos Beta a la RC

En cualquiera de los dos casos como podéis comprobar debemos o bien disponer de otra máquina nueva con la versión RC instalada o bien desinstalar la versión beta e instalar la RC, no existe un proceso de actualización de la versión Beta a la RC como tal (o al menos, como uno se esperaría cuando se habla de actualizaciones…).

Es importante tener muy en cuenta todo este proceso porque mucho me temo que la actualización de la versión RC a la versión RTM será más de los mismo!!!

Por cierto las claves de activación de la versión RC de MSCRM 2011 son:

MQM2H-JYYRB-RRD6J-8WBBC-CVBD3 (Server)
H84KC-JH8DF-7PDYK-TXBXR-2RMMT (Workgroup)

Lo curioso del caso es que al activar estas claves se advierte que tienen tan solo 90 días de duración y que pasado este tiempo debes adquirir una licencia… Suponiendo que la versión RTM saldrá en Q1 2011… entiendo que como mucho saldrá por febrero, es decir, antes de que me caduque esta versión, ¿no?…mmmmmm… no sé yo…





MSCRM 4.0: Añadir línea de separación en una sección

28 11 2010

A continuación os dejo el código que me ha pasado un cliente (con el que realizamos consultorías periódicas de mejora de su MSCRM 4.0) y que permite mostrar un título con un subrayado entre los atributos de una misma sección. De este modo no tenemos que crear varias secciones para separar o agrupar los atributos. En la imagen observareis que sobre el atributo Cuenta primaria se ha creado un título con una línea horizontal de separación:

El código de la función es el siguiente:

function lineaHorizontal(nom_obj , titulo)
{
  var obj_M = document.getElementById(nom_obj);
  if (obj_M != null)
  {
    var nodo = document.createElement('TR');
    var nodotd = document.createElement('TD');
    nodotd.colSpan=4;
    nodotd.innerHTML = "<B>" + titulo + "</B>" + "<HR>"
    nodo.appendChild(nodotd);
    obj_M.parentNode.parentNode.insertBefore(nodo , obj_M.parentNode);
  }
}

Para ejecutar el ejemplo se ha utilizado la sentencia:

lineaHorizontal("parentaccountid_c", "Ejemplo de título");




SQL: Obtener la fecha actual sin la hora

24 11 2010

Como simple curiosidad os transcribo la sentencia que he usado para obtener mediante T-SQL la fecha actual sin la hora, es decir, obtener siempre la fecha con la hora a 00:00:00. A primera vista puede parecer trivial, pero T-SQL no dispone de ninguna función específica que devuelva ese valor. GETDATE() devuelve siempre la fecha con la hora actual. Puestos a crear una función he buscado por internet la más optima y he encontrado la siguiente:

CAST(
FLOOR( CAST( GETDATE() AS FLOAT ) )
AS DATETIME
)

De todas las soluciones que he encontrado esta es la más simple y la que menos tiempo tarda en calcular la fecha.





NET: Encriptar secciones de web.config

22 11 2010

A menudo cuando desarrollamos aplicaciones Web (normalmente como extensiones de MSCRM) utilizamos el archivo web.config de la aplicación web para almacenar variables globales de la aplicaciones. Así por ejemplo, solemos añadir las cadenas de conexión a datos que posteriormente usaremos en la aplicación para conectar a bases de datos… Es muy importante saber que normalmente, el acceso al archivo web.config desde el navegador debe estar restringido pero, puede suceder que por alguna configuración ajena se permita este acceso. Por tanto, cualquier información que estemos añadiendo en este archivo de texto, puede comprometer la seguridad de nuestro sistema o puede estar ofreciendo al usuario información no deseada. En algunas instalaciones he llegado a ver que en este archivo se introduce incluso el password sin encriptar del usuario administrador de MSCRM!!!.

Figura 1. Error al acceder a web.config desde u navegador

Pues bien, además de intentar no introducir información clave en este archivo, si nos es necesario podemos optar por la opción de cifrar ciertas secciones de este archivo. Así por ejemplo, imaginad que tuviéramos definida una cadena de conexión a datos sobre la base de datos CRM en nuestro archivo web.config:


<connectionStrings>
<add name="strConn" connectionString="Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=MINHAC_MSCRM;Server=." />
</connectionStrings>

En este caso, la cadena de conexión no contiene usuario y password pues se utiliza la autenticación de Windows (la más recomendada en estos casos) para acceder al SQL Server). Sin embargo si trabajáramos con autenticación de SQL Server (poco recomendable) aparecería el usuario y la clave!!!.

Para encriptar esta sección y cifrar su contenido tan sólo necesitamos ejecutar un comando propio de NET Framework. Debemos situarnos en el directorio del NET Framework correspondiente a la aplicación Web (normalmente, si estamos en CRM 4.0, la versión de NET Framework es la 2.0) y ejecutar el siguiente comando:

Tras ejecutar este comando podremos observar que la sección connectionStrings de nuestro web.config ha sido encriptado:


<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData> <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA3I15yxfdeUywFzxPgNcnwwQAAAACAAAAAAADZgAAqAAAABAAAAB3OUG0nsxHtLh8yzBw6VtjAAAAAASAAACgAAAAEAAAAOSsEyXru5ZMGH6CC1uompVoAQAAsj8zgTP6NrsguTxVWPv0xm6Y04836QDdJ4r6yt/9XqN70ToMQABZqWnEnaSaqDDWIZaEEt/0OmJCxJXiedVomhKf2S0I+fMTBVLSLqj4pKaqSjlNjQgSfa+EoKZz5u7o3AxC4zhQS5TJ7nqdgIzIwe+upxfVUJpH0//m41u1rarWdrI/k3nUzlsvz3f7eiVyfsnk+PQ9QWXbWnIqPpFizAmGOcwbhWtk7AzT2VkMg2xdwZFYg4hpTXFYHqaU5XXocryrdHBxrj2zjE+h+4NURC3mmCd8NPEkpe2iGydJo75F1dHsuToGc9E3XRiDwHmB2dVXQkcNFxkdgS7Z6eRhJGdBVri5TYq6U1Gj8kIUe6g4CwkUnZaW8F3FjSWf3Lfl8KZLLG6OCBmwcyQEwUw06BVQah4KfKE8fHZHabI5EMWFaQ11ywsXs0YEJg+XdkHv+mUOocl3qAF+Y25GfYVgSm5JI5SyqvMHFAAAAJUDQ5kizMW2E+7oqVbIEhAbyUyK
</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>

Esta acción no requiere que en el código de la página ASP.NET en la que usemos esta cadena de conexión realicemos ninguna acción especial pues es el propio IIS el que realiza la encriptación y desencriptación y por tanto, al leer la cadena desde la págia ASPX, IIS ya realiza el descifrado.

Para recuperar el archivo original, tan sólo es necesario utilizar el mismo comando con otro parámetro:

Tan sólo hay que tener presente un par de cuestiones:

1. El cifrado depende de la máquina donde está instalado IIS por tanto, si tenemos dos entornos NO podemos copiar el archivo web.config con secciones cifradas de un servidor a otro pues en el nuevo no se interpretaría el cifrado. Debe ejecutarse el comando individualmente en ambos servidores

2. Existen dos tipos de cifrado (que indicamos en el parámetro –prov) que se pueden usar: DataProtectionConfiguratioProvider y RsaProtectionConfigurationProvider. Al desencriptar no es necesario indicar el proveedor pues ya se especifica en el archivo





ASP.NET: Declaración DOCTYPE y su efecto sobre el diseño de webforms

22 11 2010

Supongo que más de uno se habrá preguntado que significa o para que sirve el tag (o declaración) DOCTYPE que encontramos en los web form creados en Visual Studio. Tras crear un nuevo webform observaremos que se nos crea la siguiente declaración tras la directiva @Page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Pues bien, el tema tiene su miga! Para los más curiosos os recomiendo el link http://aspnetresources.com/articles/doctype.aspx donde se explica muy detalladamente el origen, significado y alguna que otra curiosidad al respecto. Pero el motivo de mi artículo no es el de explicar su significado o propósito (para eso ya hay páginas enteras). El motivo de este artículo es el comentaros una de las consecuencias una vez más de no prestar (o no tener suficiente tiempo para prestar…) atención a los que por defecto nos crea Visual Studio.

Ejemplo de webform creado en VS2008 SP1 (NET 2.0) donde se añade automáticamente el DOCTYPE

En esta ocasión tras haber creado muchas páginas ASP.NET en muchas integraciones de MSCRM he descubierto ( o mejor dicho, por fin he podido prestar atención!!!) los efectos de esa ‘inofensiva’ declaración DOCTYPE. Pues bien, los que tengáis paciencia o interesa por haber leído el link donde se describe la declaración DOCTYPE habréis comprendido, entre otras cosas, que esa declaración permite que la página tan sólo utilice objetos con compatibilidad sobre unas versiones de IE (no entraré en detalle). Pero, nunca hubiera imaginado que esa declaración afectaría al comportamiento de ciertos estilos o controles!!!

Uno de los temas en los que he dedicado más tiempo ha sido en poder crear un formulario web en el que el contenido de la página se redimensionara al variar el tamaño de la ventana. Una de las opciones que uno piensa en primer lugar és crear una tabla con altura y anchura 100%, ¿correcto?. Pues bien, si dejamos la declaración DOCTYPE que nos aparece al crear el web form, el atributo altura 100% (height en el style) NO funcionará! Por tanto, desde hace mucho tiempo he utilizado la solución del control panel y código JavaScript en los eventos onload y onresize para redimensionar el panel al cambiar las dimensiones de la ventana… Harto de ver en mil y un foros que la gente utilizaba el height 100%, me paré a investigar porqué a mí no me funcionaba y, finalmente, encontré la explicación en la declaración DOCTYPE.

Como conclusión, para poder utilizar todas las novedades del lenguaje HTML, así como las característica completas de JavaScript y, en definitiva, estar a la última, se debe eliminar la declaración DOCTYPE que añade Visual Studio al inicio de los nuevos web forms que creemos. Muy probablemente seguro que existe alguna cofiguración de VS para evitar que se cree esa declaración por defecto… si alguien la conoce o la encuentra, por favor, añadidlo en u comentarios a este artículo, gracias.

Resultado de mostrar una <table> con la dimensión height a 100% con la declaración DOCTYPE

El mismo código anterior pero sin la declaración DOCTYPE

Como observamos en el ejemplo, sin la declaración DOCTYPE la dimensión height: 100% actúa correctamente!!! Con lo cual es mucho más simple crear formularios autodimensionables sin la necesidad de usar código JavaScript para realizar la ubicación y dimensionado de los controles.

P.D.: No he entrado en mucho detalle sobre el entorno de programación… pero si creo que es importante destacar que esta situación la he encontrado creando formularios web con Visual Studio 2008 SP1 en proyectos con NET Framework 2.0 (probablemente con proyectos NET Framework 3.0 o 3.5 no ocurra esto).