Hace unos días nos encontramos con el problema de configuración de favoritos de Dynamics Ax, teníamos que crear un nuevo usuario de AX y copiar los mismos favoritos que un usuario que ya tenia configurados desde hace tiempo.
Para no tener que ir creando los favoritos a mano uno a uno y gracias a la Comunidad de AX encontramos la solución.
Para ello deberemos lanzar el siguiente job en Ax:
UserA = Usuario Origen
UserB = Usuario destino
server static void FavoritesJob(Args _args)
{
SysPersonalization FromSysPersonalization;
SysPersonalization ToSysPersonalization;
UserId FromUserId=’UserA’;
UserId ToUserId=’UserB’;
;
ttsbegin;
// Copiamos el menu de favoritos del ususario A al usuario B
while select FromSysPersonalization
where FromSysPersonalization.UserId==FromUserId
&& FromSysPersonalization.ElementType==UtilElementType::UserMenu
{
ToSysPersonalization.data(FromSysPersonalization);
ToSysPersonalization.UserId=ToUserId;
ToSysPersonalization.doInsert();
}
ttscommit;
}
Entramos a AX, abrimos el AOT y generamos un nuevo JOB.
Copiamos el job cambiando los nombre de usuarios y lo ejecutamos.
En ocasiones, por diferentes motivos (rollups, problemas con .net, etc…) es necesario reinstalar nuestro cliente de Ax.
Una vez se ha desinstalado el cliente y cuando se procede a la re-instalación podemos encontrarnos con errores.
Si abrimos el fichero de log de la instalación veremos el detalle de error:
" === Iniciando fase de ejecución ===
=== Instalando Componentes ===
Iniciando MSI: /i "C:\DynamicsAx\CD AX2009\Msi\Components64\Components64.msi" /qb-! /l*v "C:\ProgramData\Microsoft\Dynamics AX\Dynamics AX Setup Logs\2013-12-17 15-56-09\Components64 Log.txt" DIRECTEXECUTE=1 SETUPLANGUAGE=ES INSTALLDIR="C:\Program Files\Microsoft Dynamics AX\50" INSTALLDIR32="C:\Program Files (x86)\Microsoft Dynamics AX\50" ADDLOCAL="ClientUI,ClientConfig"
Error durante la instalación de Componentes."
Si queremos mas detalle en el fichero de log de Components64 tenemos mas datos sobre los componentes que están fallando.
Para solucionar este error deberemos reinstalar el .net framework (no hace falta una versión especifica sino la que ya tengamos en el PC). Una vez realizado este paso ya podremos volver a instalar el cliente de Ax. Este problema está documentado en la página de Support de Microsoft.
http://support.microsoft.com/kb/2290614
Otra de las problemáticas que nos puede surgir con la instalación del cliente de Ax 2009 es la versión de .net framework activa sobre un Windows x64, este problema se soluciona modificando una clave de registro, esta clave se modifica ejecutando en modo administrador en una cmd el siguiente comando:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe set64
Esto también s en cuenta en la web de MSDN
RDCMan es la herramienta gratuita de Microsoft para la gestión de conexiones de escritorio remoto.
Esta herramienta permite administrar y centralizar en una única consola tantas conexiones como sean necesarias y agruparlas según las necesidades para poder organizarlas correctamente.
Es útil para la gestión de los laboratorios o de grandes granjas de servidores donde se necesita un acceso regular a cada máquina.
Como he comentado es gratuita y está disponible en el Donwload Center.
Para implementar esta función de Dynamics AX 2009 deberemos entrar con nuestro cliente de Ax e irnos a Administración, Configurar y abrir el formulario «Parámetros de correo electrónico».
Una vez abierto deberemos rellenar los campos:
En nuestro caso introduciremos un servidor smtp de prueba, dejaremos como nombre del equipo local y estableceremos el puerto 25 como puerto del servidor de smtp. Introducimos nuestro nombre de usuario y nuestra contraseña. No utilizaremos NTLM (autenticación Windows).
Como parámetros introduciremos un límite de tamaño para los datos adjuntos de 10Mb y la ruta desde donde permitiremos adjuntar los archivos vinculados.
Hay que tener en cuenta que no todos los servidores smtp permiten realizar este tipo de envíos (por seguridad) están capados/limitados. Para poder verificar servidores smtp copio link a una herramienta que chequea el servicio de smtp.
http://www.dnsqueries.com/es/smtp_test_check.php
Tampoco se permite la configuración con google apps.
Una de las ventajas de la integración de Ax con el Active Directory es la exportación de los usuarios ya definidos dentro de nuestro controlador de dominio. Para poder realizar esta tarea deberemos tener definidos dentro de nuestro AD los diferentes usuarios. Para esta prueba he creado el usuario prueba_exp_ax.
Dentro de Ax, accedemos a ADMINISTRACION y dentro del formulario común seleccionamos usuarios.
Seleccionar la opción de Importar.
Seleccionamos el dominio donde tenemos definido nuestro usuario (podemos tener más de un dominio) y también introducimos el nombre del usuario a importar (si no ponemos el nombre nos aparecerá el listado entero de usuarios del AD, podremos seleccionar varios usuarios para exportaciones masivas).
Marcamos check de importar.
Vemos el usuario (los usuarios si hemos seleccionado más de uno) que se importará.
Añadimos el grupo al que queremos que pertenezca este nuevo usuario, en este caso admin.
Seleccionamos el tipo de perfil que tendrá en cada empresa, en este caso tendrá el mismo perfil para todas las empresas.
Y ya tendremos agregado a Ax nuestro usuario.
Ahora volvemos a acceder a usuarios y verificamos que nuestro usuario se ha generado.
No sé cuántas veces he escuchado ya la famosa pregunta “¿Que versión de SQL Server instalamos?”
Se responde fácilmente y con otra pregunta “¿Qué queréis montar?”
Bien, Microsoft tiene un comparador de las diferentes versiones de SQL Server donde se puede ver de forma muy intuitiva/clara los diferentes componentes/limitaciones que tiene cada versión.
http://www.microsoft.com/es-es/sqlserver/product-info/compare.aspx
En la siguiente captura de pantalla se comparan todas las versiones en cuanto a escalabilidad y rendimiento:
Hay muchas más opciones a comparar:
Así como la posibilidad de seleccionar solo las versiones que se requieran comparar.
Fuente: Microsoft
Hace un año comenzaba blog y por qué no decirlo aventura, sería capaz de mantener el blog vivo? Pues 365 días después sigue activo, cierto es que no escribo todo lo que me gustaría escribir.
Actualmente, contando esta entrada hay creadas 28, eso sale más o menos a 2,33 al mes, tampoco esta tan mal… “Al loro!!! No estamos tan mal!!!” 🙂
Bueno después de este año sigo motivado y con ganas de seguir adelante, es más, espero introducir cambios muy pronto.
Gracias a todos los que de manera directa o indirecta se pasan por aquí.
Always On es el grupo de funcionalidades de alta disponibilidad incorporadas en SQL Server 2012 (no es una tecnología, es una agrupación de varias tecnologías).
Estas tecnologías tiene nuevas capacidades que proveen de alta disponibilidad a bases de datos (tanto BBDD de aplicación como a nivel de instancia de BBDD), lo cual proporciona varias configuraciones de alta disponibilidad:
AlwaysOn Availability Group. Permite la creación de hasta 4 réplicas secundarias desde una base primaria, con la posibilidad de realizar un failover a cualquiera de las réplicas y la gran novedad de que cada réplica puede ser usada como base de datos de solo lectura o como origen para una operación de backup .
AlwaysOn Failover Cluster Instance. Soporte de cluster para la instancia entera. Políticas flexibles para mejorar el control del failover y Multisite con sub-redes (podemos tener por ejemplo las réplicas en diferentes datacenters).
Hay que indicar que tanto AlwaysOn Availability Group y AlwaysOn Failover Cluster Instance utilizan el Windows Server Failover Clustering.
Dejo vídeo con overview del producto.
Por defecto SharePoint 2010 establece un tamaño máximo de subida de fichero en 50 Mb, pero en ocasiones es necesario aumentar dicho tamaño.
Hace unos días por necesidades de un proyecto debimos modificar esta configuración y aumentar este limite a 100 Mb, para realizar este cambio debemos seguir los siguientes pasos:
– Entrar en la Central Administration, dentro de Application Management entrar en Manage Web Applications.
– Seleccionar la Web Application que corresponda y entrar en General Settings.
– Buscamos el campo Maximun Upload Size y modificar al tamaño máximo que deseemos (en nuestro caso 100 Mb).
Tendremos que tener en cuenta también el timeout de IIS a la hora de subir un fichero, ya que si aumentamos el tamaño máximo de subida a un valor muy alto quizás tengamos que aumentar este valor que por defecto esta a 120 segundos (en mi caso no fue necesario aumentar este valor).
Para realizar esta tarea debemos acceder al IIS, dentro de Sites seleccionamos el site que corresponda y accedemos a las Advanced Settings, una vez aquí tenemos que buscar dentro de Connection Limits el campo Connection Time-Out (seconds) y modificar al valor que necesitemos.
La configuración para SharePoint 2007 no dista mucho de la de 2010 pero dejo un enlace de cómo hacerlo para esa versión.
Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2012 de este blog.
Aquí hay un extracto:
600 personas llegaron a la cima del monte Everest in 2012. Este blog tiene 1.900 visitas en 2012. Si cada persona que ha llegado a la cima del monte Everest visitara este blog, se habría tardado 3 años en obtener esas visitas.
Aaron´s Tecnoblog 