miércoles, 20 de marzo de 2013

SHP - Error inesperado

Buenas,

Para tener más información del "Error inesperado / an unexpected error has occurred", deberemos modificar el web.config del site que estemos accediendo (sharepoint 80 si es el de por defecto).

Deberemos buscar el tag

<SafeMode MaxControls="200" CallStack="false"... y ponerle

<SafeMode MaxControls="200" CallStack="true"

Luego buscaremos el tag <customErrors mode y lo pondremos a Off (por defecto estará en On). 

Y ya está. El cambio es dinámico, es decir, no hace falta reiniciar IIS. 

jueves, 28 de junio de 2012

AX: Evitar error de Windows al iniciar el servicio AOS


Por defecto, si un servicio de Windows tarda más de 30 segundos en iniciarse el sistema da un aviso. Aunque a menudo este aviso no afecta al funcionamiento del servicio que iniciará finalmente, a veces puede hacer que el servicio no termine de funcionar. Esto ocurre a veces con el servicio AOS de Dynamics AX si el servidor no es lo bastante potente o cuando se realizan tareas de reconstrucción de objetos de la aplicación, etc.
Para evitar este problema se puede ampliar este tiempo de 30 segundos a, por ejemplo, 60 segundos, de esta manera:
  • Abrir el registro de windows (Inicio > Ejecutar > Regedit), abrir la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
  • Localizar dentro de este elemento la clave ServicePipeTimeout, si no existe crearlo haciendo click-derecho en el elemnto Control > New > DWORD (32-Bit) Value  
  • Hacer click-derecho en ServicePipeTimeout > Modificar
  • Introducir el valor de tiempo deseado (en milisegundos), en este ejemplo actualizar a 60000 (60 seg.), pulsar OK y cerrar el registro.
ATENCION!! Modificar el registro de Windows en un servidor puede provocar situaciones impredecibles. Utilizar este procedimiento bajo su propia responsabilidad!

miércoles, 27 de junio de 2012

CRM - El usuario ya existe

Casuística: Si existe un usuario de CRM al que le cambia el ID de Active Directory (porque se eliminó el usuario en AD y luego hubo que volver a darlo de alta o cosas así).

En CRM no se pueden eliminar los usuarios.

De hecho, es una acción no recomendada por Microsoft.

Lo óptimo sería crear un nuevo usuario en AD que se llamase distinto (para que fuese todo más limpio). Pero si no quieren, ahí  va la solución:

Cuando un usuario deshabilitado se llama igual que uno nuevo, se deben llevar a cabo estos pasos:
1.- Crear un nuevo usuario en el AD para uso temporal (ej: CRMTemp)
2.- Editar el usuario deshabilitado e indicarle el nombre de dominio\CRMTemp (esto refrescará los IDs).
3.- Guardar.
4.- Editar de nuevo el usuario y modificarle el nombre de usuario volviendo a ponerle el nombre original.
5.- Habilitar y guardar.


* Otra opción es reimportar la organización y, en el mapeo de usuarios, asociar ese nombre de usuario con el nuevo usuario.

Estas son las 2 únicas opciones viables que me vienen a la cabeza.

jueves, 21 de junio de 2012

Ver SPNs duplicadas

Buenas,

Esta entrada será cortita.

Para ver las SPNs duplicadas podemos ejecutar esto en un cmd:

spn -x

Esto nos devolverá todas las SPNs duplicadas.

Config Kerberos en NAVision 2009

Si tenemos en un servidor SQL y en otro los servicios de NAV, tendremos que configurar kerberos para acceder a los webservices y al cliente RTC. 

Las SPNs a crear son:

* Para SQL [SPN para la cuenta que levanta el servicio de SQL]
MSSQLSvc/ServidorSQL:1433
MSSQLSvc/FQDN_ServidorSQL:1433

Si el servidor SQL está en clúster,  también añadiremos una SPN sin puerto. Es decir:
MSSQLSvc/ServidorSQL
MSSQLSvc/FQDN_ServidorSQL

* Para los webservice [SPN para el usuario que levanta el servicio de webservice]
HTTP/ServidorNAV
HTTP/FQDN_ServidorNAV

* Para el servicio RTC [SPN para el usuario que levanta el servicio RTC]
NombreInstanciaNAV/ServidorNAV:7046
NombreInstanciaNAV/FQDN_ServidorNAV:7046

Por ejemplo: setspn -a DynamicsNAV/servidor01:7046 dominio\usuario

Si tenemos varias instancias de NAV, deberemos poner todas las que tengamos. 
Las SPNs de HTTP no distinguen puerto, por lo que es importante no crear una para el puerto 7047 y otra para el 80, etc. porque si no lo detecta como SPN duplicada y no funciona kerberos. 

En AD, los usuarios que levanten el servicio de SQL y NAV deberán tener la pestaña de delegación activa. Es decir, en las propiedades del usuario, en la pestaña Delegación, deberá tener marcada la opción "Trust this user for delegation to any service (Kerberos only)".

ADFS20 - Error certificado revocado

Hola,

Casuística: Cuando intentamos acceder al site (en mi caso CRM) y nos devuelve directamente un error de STS1.

Vamos a los visores de sucesos\ADFS\Admin y vemos que hay un error diciendo algo del estilo a
"An error occurred during an attempt to build the certificate chain for the relying party trust 'https://site:444' certificate identified by thumbprint 'xxxx'. Possible causes are that the certificate has been revokes, the certificate chain could not be verified as specified by the relying party trust's encryption certificate revocation settings or certificate is not within its validity period".

Solución: Evidentemente, lo primero a mirar es que el certificado no esté caducado. Pero si tenemos el certificado en perfectas condiciones, abrimos una powershell y escribimos


Add-PSSnapin Microsoft.Adfs.PowerShell

Set-AdfsRelyingPartyTrust -TARGETNAME "Nombre identificador de la Relying Party interna" -EncryptionCertificateRevocationCheck "None"

Set-AdfsRelyingPartyTrust -TARGETNAME "Nombre identificador de la Relying Party externa" -EncryptionCertificateRevocationCheck "None"

Y listos. Al acceder al site deberá salirnos correctamente la pantalla de login de ADFS y autenticarnos correctamente.

viernes, 18 de noviembre de 2011

AX - Error SysServerSessions

Buenas,

si el aos se vuelve loco y no acaba de iniciar o si inicia, pero a los usuarios les devuelven errores del estilo "usuario no reconocido en Ax", "no hay conexión con SQL", "error system sequence", "error sysserversession" ... tenemos 2 posibles soluciones:
  • Eliminar las stores procedures SysServerSession y SysClientSession
  • Copiar el contenido de SysServerSession y SysClientSession de una instalación de Ax que esté funcionando.

miércoles, 16 de noviembre de 2011

Autenticación Kerberos y Firefox

Buenas,

si estáis intentando acceder a alguna página web con autenticación kerberos y no hay manera de que se os muestre el contenido por los maravillosos errores de autenticación, probad lo siguiente.

Abrid un navegador firefox y escribir about:config en la barra de navegación.

Picamos el botón de “¡Tendré cuidado, lo prometo!”

Se nos abrirá una página con varios parámetros configurables de firefox. En el filtro podemos escribir auth para que nos muestre sólo los parámetros que nos interesan y sea más fácil modificarlos.

Debemos modificar 2 parámetros:

- network.negotiate-auth.delegation-uris
- network.negotiate-auth.trusted-uris

Nos ponemos sobre el parámetro\botón derecho -> Modificar

Aquí escribimos la url a la que intentamos ir, por ejemplo: erp.dominio.net

Lo mismo para el otro parámetro.

Cerramos todos los navegadores firefox que tengamos abiertos.

Cuando volvamos a abrir firefox ya podremos ver correctamente la web (nos pedirá autenticarnos 4 veces si el site no está en mis sitios de confianza).

AX - Auditar campos

Buenas,

en ocasiones nos interesará saber quién ha modificado x campo.

Para ello , vamos al módulo de Administración vamos a configurar\Registro de base de datos
En el formulario que se nos abre, le damos a “Nuevo”. Esto dará paso a un asistente para configurar las tablas que queremos auditar:
En la siguiente página seleccionaremos los dominios que queramos auditar:
En la siguiente página podemos escoger ver las tablas principales o mostrar todas las tablas.
Al desplegar los diferentes apartados, podremos marcar las tablas y/o campos que deseamos auditar.
En la siguiente página deberemos escoger qué queremos dejar registrado: cada vez que alguien inserte/actualice/elimine/asigne un nuevo nombre a la clave de la tabla auditada o cada vez que alguien modifique el campo auditado.
En la siguiente página nos muestra un resumen de lo que estamos registrando:
Cuando vayamos a Administración\Consultas\Registro de base de datos veremos los cambios realizados.
Si vamos a Administración\Informes\Registro de base de datos nos devolverá un informe detallado con los resultados de la auditoría.

AX - cómo replicar entornos

Un hecho recurrente en Ax es copiar entornos. Por ejemplo, tenemos el entorno de test desactualizado y queremos actualizarlo con lo que hay en producción.

Para hacer esto deberemos hacer backup de la carpeta de aplicación y de la BDD del entorno de test. Siempre recomiendo backup para poder dar marcha atrás o recurrir a esos archivos en caso de necesitarlos más adelante.

Paramos AOS de test, copiamos el contenido de la carpeta de aplicación de producción en test (importante mantener el nombre de la carpeta de test si no queremos tocar nada de la configuración del AOS y clientes).

Paralelamente, restauramos BDD de producción en Test.

Una vez ha finalizado, en la carpeta de aplicación de Test eliminamos el fichero .aoi e iniciamos el AOS de test.

Es normal que nos aparezca un mensaje del estilo "el servicio de aos no se ha podido iniciar en el tiempo estimado, espere". Esto es porque no está creando el archivo .aoi generando los nuevos índices.

Esperamos un poco y, una vez iniciado el aos, entramos en ax_test para verificar que tenemos el entorno replicado :)

AX2009 - Error PeriodYear en Role center

Buenas,
quien instale centro de roles y funcione todo a la primera: chapeut.

Para el resto, puede que resulte interesante este post :)
Desde el formulario de administración de OLAP\Pestaña Avanzado, Marcamos "actualizar datos BI" y pulsamos "Actualizar bases de datos", este proceso creará datos en la tabla "LedgerPeriodDuimensions".
Una vez hecho esto , hemos de procesar la dimension "Ledger Period Time dimension" desde la consola SQL management studio (Analysis services).

Y ya está, un problema menos ;)

jueves, 26 de mayo de 2011

MSCRM - Eliminar cola email router

Si lanzamos una campaña y queremos eliminarla, aunque paremos el email router, cuando se ponga en marcha, lanzará los mails igualmente.

Para solucionarlo debemos limpiar la cola de mails en estado 'listos para enviar'. Esto lo haremos desde SQL modificando la vista Email:
- Por un lado cambiamos el estado de abierto a completado:
update Email
set statecode=’1’ where statecode=’0’
- Por otro lado cambiamos el estado del mail de “envío pendiente o enviando” a “enviado”
update Email
set statuscode=’3’ where statuscode=’7’ or statuscode=’6’

Y ale, ya podemos arrancar con tranquilidad email router que no enviará estos mails. Ojo, que esto te limpia toda la cola, se puede filtrar por subject, por ejemplo, si sólo queréis "eliminar" el envío de una campaña en concreto.

Mirroring SQL

COMPROBACIONES PREVIAS:

Cuenta de administrador para servicio MSSQL y Agente SQL.

BDD con modo de recuperación completa.

Conectamos al SQL Management Studio primario.

Hacemos backup de la BDD a montar el mirroring.

Vamos al SQL Management Studio del servidor secundario.

Creamos una base de datos que se llame igual que la bdd primaria (si los archivos pueden estar en la misma ruta, mejor que mejor). Restauramos el backup de la bdd del servidor primario. (si se ha hecho algún transaccional desde que hemos hecho el backup completo hasta que hemos montado el mirroring, deberemos restaurar el backup transaccional del primario en el secundario).

Volvemos al SQL Server Management Studio vamos a propiedades de la base de datos primaria\Creación de reflejo\Configurar seguridad

Seleccionamos que no haya testigo (puesto que sólo son 2 máquinas, no hay una 3ª de testigo). Siguiente. Seleccionamos primero el servidor primario (en el que estamos). Siguiente. Seleccionamos el servidor secundario/reflejado. Tras seleccionarlo, le damos a conectar. Siguiente. Si el servicio sql lo levantasen usuarios diferentes en ambas máquinas, aquí definiríamos el usuario que levanta el servicio en el servidor primario y el que lo hace en el secundario. Pero si es el mismo usuario en ambos servidores, lo dejamos en blanco. Finalizar.

Para dejar activo sólo el nodo secundario (en caso de haber problemas con el nodo primario), deberemos ejecutar la siguiente sentencia en SQL Management Studio:

ALTER DATABASE “Produccion” SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Aumentar Tiemout IIS

Para cuando disponemos de un servidor chustero y una web densita. Podemos aumentar el timeout de nuestros sites del IIS para poder ver la página, deberemos tener en cuenta que tardará tiempo en cargar la página, pero acabará cargándola en vez de devolviéndonos error.

Vamos al administrador de IIS.
- Para IIS7: vamos al site\botón derecho\configuración avanzada. Desplegamos comportamiento\Límite de conexiones\Tiempo de espera de la consexión. Por defecto está a 120 segundos. Podemos ponerle 360, a ver si así nos llega a cargar la página.

- Para IIS6: vamos al site\botón derecho\propiedades. En la pestaña 'Web site' veremos el Connection Timeout a 120segundos. Lo ponemos a 360 y vemos si carga la página.

También lo debemos cambiarlo en el web.config. Buscáis el tag
httpRuntime maxRequestLength="51200"

y los sustituís por

httpRuntime executionTimeout="3600" maxRequestLength="51200"


Y... Ya Ta' [a lo Hiro Nakamura] :)