Problemas con cambio de zona horaria en Argentina y Microsoft CRM 3.0 - Parte 2

En la entrada anterior Problemas con cambio de zona horaria en Argentina y Microsoft CRM 3.0 - Parte 1 comentamos sobre los problemas que se producían al modificar el huso horario.

No quedó pendiente el caso en el que realizamos la modificación del huso horario sin tener instalado previamente el rollup 2 de Microsoft CRM 3.0.

ATENCION: EL SIGUIENTE PROCEDIMIENTO INVOLUCRA LA MODIFICACIÓN DEL REGISTRO. LAS CLAVES A MODIFICAR VARÍAN SEGÚN LA REGIÓN. EN ESTE CASO SE DESCRIBEN SOLO LAS CLAVES DE REGISTRO PARA EL CAMBIO DE HUSO HORARIO EN ARGENTINA.

Los pasos a realizar son los siguientes:

• En el servidor de CRM ir a, Inicio -> Ejecutar -> Regedit.
• Eliminar las siguientes claves del registro.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Argentina Standard Time]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Argentina Standard Time\Dynamic DST]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\SA Eastern Standard Time] "Display"="(GMT-03:00) Georgetown"

• Reiniciar el servicio "horario de windows" (Windows Time).
• Instalar Update Rollup 2 for Microsoft Dynamics CRM 3.0.
• Iniciar una vez mas el script para la modificación de la fecha.
• Reiniciar el equipo.

Esto es todo.

Saludos

Problemas con cambio de zona horaria en Argentina y Microsoft CRM 3.0 - Parte 1

Hola a todos,

Como sabrán el cambio de hora (invierno-verano) es una práctica generalizada en muchos países a fin de racionalizar la energía. Argentina no estuvo al margen de ello.

Las siguientes fechas indican el comienzo y la culminación del horario de verano definido:

El horario de verano comienza: el domingo 30 de diciembre de 2007 a las 00:00, hora local.

El horario de verano culmina: el domingo 16 de marzo de 2008 a las 00:00, hora local de verano.

Actualmente, las computadoras en Argentina están configuradas según el huso horario “(GMT-03:00) Buenos Aires, Georgetown”. Sin embargo, los valores predeterminados para dicho huso horario “(GMT-03:00) Buenos Aires, Georgetown” no reflejan las fechas de inicio y culminación del horario para el período estival definidas por las Autoridades Nacionales según lo anteriormente señalado.

Microsoft ha publicado un script el cual genera algunas claves del registro. Esto creará un nuevo huso horario denominado “(GMT -03:00) Buenos Aires”



Pava obtener mas detalles sobre el procedimiento Sepa como realizar el cambio de huso horario

Ahora bien, el problema se presenta al hacer este cambio en nuestro servidor de Microsoft CRM si este no tiene instalado previamente el Update Rollup 2 for Microsoft Dynamics CRM 3.0. Entre sus Fix esta "update for the 2007 daylight saving time changes" el cual prevee esta modificación de huso horario.

En el caso de haber realizado la actualización del huso horario sin previamente instalar el rollup 2 de Microsoft CRM 3.0 vamos a encontrar los siguientes inconvenientes al utilizar la aplicación:

Al Crear, Modificar una actividad da un error inesperado.

No se pueden crear nuevos campos en la personalización de las entidades.

En una segunda parte les comentaré como solucionar este problema si Microsoft CRM no estaba actualizado con el rollup 2 y la actualización del huso horario fue realizada.

Hasta entonces...

Saludos

CrmDiagToolTurbo para Microsoft CRM 3.0

Hola a todos,

Les dejo disponible una buena herramienta que generalmente utilizan desde el soporte de Microsoft, para habilitar las distintas instancias de logging para la versión 3.0 de CRM.

Por supuesto no hace nada que no se pueda hacer manualmente, pero si facilita mucho las cosas a la hora de tener que hacer un seguimiento como ser un Trace o Debug de las distintos componentes de CRM ya sea: CRM Server, CRM Client (Microsoft CRM para outlook), CRM Email Router, Reporting Services, etc.

Microsoft CRM 3.0 Diagnostic Tool

Saludos

Seguridad en las reglas de Workflow en Microsoft CRM 3.0

Hoy quería comentarles un problema que tuve hace un tiempo con con los Wokflows en Microsoft CRM 3.0.

Es una practica común abrir el Workflow Manager (Administrador de flujos de trabajo) para crear alguna regla de Workflow y hacerlo con el administrador de CRM... y acá empezó mi problema.

El problema básicamente era que tenía una regla sobre la entidad de cuenta creada con una cuenta de usuario con el rol de administrador de CRM. La regla era algo muy sencillo, "Al crear una cuenta enviar un e-mail a la misma dándole la bienvenida como cliente".

Por supuesto active la regla y al crear una cuenta... nada. No se disparaba la regla. Probé reiniciando el servicio de Workflow.. y nada tampoco.

En el visor de eventos encontraba el siguiente error:

Condition {7565170E-646D-DC11-9B9A-001320950F24} failed in step {7265170E-646D-DC11-9B9A-001320950F24} of process instance {6A65170E-646D-DC11-9B9A-001320950F24}. Please view the paused rule in the Microsoft.Crm.Workflow.Monitor for more information about the failure.

Y en el Monitor de flujos de trabajo??.. ni la regla aparecía, mas allá que el error logueado en el visor de eventos indicaba que para obtener mas información lo verifique allí.

Después de varias idas y vueltas encontré el problema. El usuario con el que creé la regla estaba en modo de acceso restringido. Esto era así por que el usuario cumplía el rol de administrador de CRM y no de usuario de la aplicación, y no tenia sentido utilizar una licencia con ese usuario.

La explicación del por que no funciona se basa en que las reglas automáticas (no manuales) se impersonan, es decir, se ejecutan bajo los permisos del usuario que creó la regla.

En este caso como el usuario estaba en modo de acceso restringido no podía realizar las acciones que pretendía la regla de Workflow realizar.

Aprovecho la oportunidad para comentarles algunas otras cosas a tener en cuenta sobre el usuario que crea las reglas de Workflow son:

• Si el usuario que propietario de la regla pertenece a la unidad de negocios principal, la regla se aplica a la unidad de negocios principal y todas las unidades de negocios que dependen de ella.
• Se desprende del hito anterior, que para crear reglas que sean disparadas para una unidad de negocio en particular y todas sus "hijas", el Workflow se debe crear con un usuario de dicha unidad de negocios.
• La cuenta de usuario que crea la regla debe tener privilegios de acceso a nivel de organización sobre Procesos e Instancias de procesos.
• La cuenta de usuario que crea la regla debe tener privilegios para realizar las acciones que en el Workflow se realizan.

Otro dato importante a tener en cuenta es que al reasignar registros del propietario del Workflow, este no se reasigna.

Como conclusión, verifiquen antes de crear una regla de Workflow, con que cuenta de usuario lo van a realizar!!.

Saludos

Instancias nombradas de SQL Server y Microsoft CRM 3.0

Hola a todos.
Hoy voy a escribir sobre algo que en un principio era una restricción para la implementación de Microsoft CRM 3.0.

Microsoft CRM 3.0 no se puede instalar sobre una instancia nombrada de SQL Server.

La realidad es que ya hace bastante tiempo que esto es soportado por el equipo de desarrollo de CRM, el problema es que el asistente de diagnostico de entorno que verifica los pre requisitos para la instalación, no nos permite comenzar con la instalación si encuentra que la instancia de SQL es nombrada.

El problema se da por que el equipo de desarrollo comenzó a soportar este tipo de instalación una vez liberado el release de Microsoft CRM 3.0, por lo tanto el control de pre instalación sigue verificando que la instancia no sea nombrada.

Me decidí a realizar este post, (aunque no sea una novedad), por el hecho de que todos comentan que esta soportado pero pocos explican como poder instalarlo en este entorno.

Vamos al grano, para poder realizar la instalación lo que debemos hacer es un bypass del asistente del diagnostico de entorno.

Para lograrlo hay que hacer lo siguiente:


1. En el servidor de Microsoft CRM, click Inicio, click Ejecutar, y tipear regedit .
2. Abrir la siguiente clave del registro: HKEY_LOCAL_MACHINE\Software\Microsoft
3. Si la clave de registro MSCRM ya existe, ir al punto 6. Si la clave de registro MSCRM no existe ir al punto 4.
4. Click derecho sobre Microsofr, Nuevo, y hacer click en clave.
5. Tipear MSCRM como nombre de la clave del registro.
6. Click derecho sobre MSCRM, Nuevo, click sobre el calor DWORD.
7. Tipear IgnoreChecks como nombre, presionar ENTER.
8. Click derecho sobre IgnoreChecks, y luego click en modificar.
9. En la caja de texto tipear el valor 1 , click Aceptar.
10. En el asistente de diagnostico de entorno, click en Atras, y luego click en siguiente para volver a iniciar el chequeo del asistente de diagnostico de entorno. Notaremos que el error sigue apareciendo. Sin embargo, el boton de Siguiente ahora estará habilitado. Click Siguiente. Ignorar los mensajes de error.

Bueno eso es todo

Saludos y hasta la próxima!.