Suena como un anuncio de colonia, ya lo sé. El caso es que me he encontrado con algunos problemillas (qué sorpresa) y aquí van, para que no se olvide. En líneas generales, el proceso que se explica en la carpeta RedeploymentTool es correcto. Sólo añadir que:
- El backup de la base de datos original no debería incluir los usuarios (SQLAccessGroup y demás) que crea la instalación de CRM. Estarán basados en el directorio activo antiguo. Aunque se vaya a instalar sobre el mismo directorio activo, no conviene que estén, pues la instalación intentará volver a crearlos y dará un error, poco explicativo, por cierto de tipo GrantDatabaseAccessAction.
- Puede que dé un error AddLicenseAction. Se puede omitir, como recomienda Matt Parks aquí, pero también se puede entrar a la base de datos, tabla Licenses, y cambiar (por ejemplo) una letra de la clave de activación. El programa de instalación machacará esta tabla, en cualquier caso.
Por lo demás, todo fue bien, aunque me sorprendió no encontrar demasiada información en la web sobre Redeployment. Es una herramienta fundamental para fabricar entornos de prueba.
Suena como un anuncio de colonia, ya lo sé. El caso es que me he encontrado con algunos problemillas (qué sorpresa) y aquí van, para que no se olvide. En líneas generales, el proceso que se explica en la carpeta RedeploymentTool es correcto. Sólo añadir que:
6 comentarios:
Hola Dani,
Efectivamente hay poca ayuda de reimplementación de CRM en la red.
Como bien sabes debo ponerme al dia la implementación en el la imagen virtual para poder crear un entorno de desarrollo CRM.
Tengo dudillas (lógicas debido a mi lerdo conocimento de backups de SQL) sobre como debo hacer exactamente el backup para que el redeployment sea efectivo.
Podrias hacerme un pequeño croquis?
gracias.
Hola, "Xarz". Lo único que hay que tener en cuenta es que no se deben incluir los usuarios en el backup. La instalación de CRM crea una serie de usuarios en las bases de datos: si ya existen, la reimplementación falla. Así que mejor no incluirlos (o borrarlos después, como quieras). En concreto, son SQLAccessGroup y ReportingGroup. Por cierto, si se reimplementa sobre el mismo dominio, no hace falta eliminarlos.
Buenos dias Daniel,
llevo dos semanas con un intento de redeployment y estoy que me quiero morir porque me da el error GrantDatabaseAccessAction y no hay manera de saltarmelo, he seguido los pasos que das a xarz de borrar los usuarios y esquemas de SQLAccessGroup y ReportingGroup, pero nada, no he conseguido sobre pasar ese error.
Los pasos que he realizado son:
1.- Instalar la herramienta del redeployment en mi servidor destino.
2.- he hecho un backup de las tablas METABASE y MSCRM dek servidor origen.
3.- Las he copiado al servidor destino y las he restaurado en el SQL Server 2005.
4.- Borro lo antes indicado
5.- Le paso la herramienta de CRM Redeployment
6.- Intento instalar el CRM
7.- Se me fastidia la instalacion por el GrantDatabaseAccessAction.
8.- Me dan ganas de suicidarme...
9.- Te pido ayuda a ver si me puedes decir algo.
Muchas gracias,
Guillermo Estévez
Buenos dias Daniel,
estoy teniendo problemas haciendo un redeployment, he seguido tus comentarios incluyendo la ayuda que le das a xarz, pero no consigo evitar el error de GrantDatabaseAccessAction.
Alguna otra idea?
Muchas gracias por la ayuda,
Guillermo
Hola, Guillermo. Después de escribir este articulillo me di cuenta de que parte de los problemas venían por lo siguiente: había dado permisos directos sobre tablas a determinados usuarios de la implementación. No sé si será tu caso. Lo que sí parece es que el redeployment va a buscar un usuario que no existe, como cuentan aquí y también aquí. ¡Suerte!
la solucion estaba en tu aqui tambien
Muchas gracias, que sepas que si pasas por madrid y me mandas un correo a mi cuenta de google/blogger, tienes unas cervezas ganadas
Publicar un comentario