Archivo de Junio de 2015 En diferentes situaciones necesitaremos crear Relaciones de Confianza en Directorio Activo, entre diferentes Dominios de diferentes Bosques, incluso en algunos casos desearemos que confíen entre sí todos los Dominios de un Bosque con todos los Dominios de otro Bosque, para lo cual, deberemos crear una Relación de Confianza de tipo Bosque (Forest Trust). Sin embargo, este tipo de relaciones de confianza tienen algunas peculiaridades que podemos necesitar conocer, para una correcta planificación y ejecución de la misma, y para su posterior mantenimiento. Cuando tenemos que tocar Directorios Activos que no son nuestros, una de las cosas que tendremos que averiguar, es cuál es el Dominio Raíz de Bosque (Forest Root), algo que no es tan evidente cuando se trata de un Bosque formado por múltiples árboles. Si tenemos con quien hablar, para que nos lo cuente, genial. Sino, tendremos que averiguarlo por nuestros propios medios. Una forma de conseguirlo es utilizando la herramienta administrativa ADSI Edit, para conectarnos al RootDSE, y así comprobar el valor de la propiedad rootDomainNamingContext. Durante la creación de un nuevo Dominio de Directorio Activo con dcpromo, podemos encontrarnos con errores de validación de DNS, partiendo del mensaje genérico Warning: Domain Controller functions like joining a domain, logging onto a domain, and Active Directory replication will not be available until the DNS infrastructure for Active Directory is correctly configured, a partir del cual deberemos de revisar el mensaje de error específico que estamos obteniendo para su correcto análisis y resolución. Una tarea que necesitaremos en más de una ocasión, es poder descargar una o varias Soluciones instaladas en nuestra Granja de SharePoint, de tal modo, que tengamos acceso al fichero de Solución (WSP) desde el filesystem, ya sea con fines de inventariado, para análisis durante un proyecto de migración, como medida de contingencia para poder dar la marcha atrás antes de instalar una versión posterior, etc. Afortunadamente, podremos hacerlo directamente desde la SharePoint Management Shell (PowerShell), aunque adicionalmente existen herramientas de terceros para ayudarnos en este tipo de tareas. La configuración de un Cluster Multi-Site habitualmente requerirá la configuración de las propiedades RegisterAllProvidersIP y HostRecordTTL, para conseguir de este modo que se registre en DNS sólo y únicamente la Dirección IP que está levantada, y además que se cree el correspondiente registro DNS con un TTL bajo, de tal modo que ante una situación de balanceo que implique un cambio de Dirección IP, los equipos cliente no tarden demasiado tiempo en darse cuenta, y así minimizar la indisponibilidad del servicio. El presente artículo explica cómo configurar las propiedades RegisterAllProvidersIP y HostRecordTTL del Recurso Network Name utilizando PowerShell. En el presente artículo describimos la configuración básica de un Cluster Multi-Site sobre Windows Server 2008 R2 y SQL Server 2012 con AlwaysON, una solución de Alta Disponibilidad apropiada para Cluster Geográficos, sin necesidad de tener que utilizar VLANes extendidas (ahorro de costes), aunque con algunos inconvenientes que como veremos en el próximo artículo, se pueden solucionar fácilmente para conseguir un funcionamiento correcto del Cluster Multi-Site. Recientemente al realizar un IISRESET en una máquina de pruebas, descubrimos que ningún intento de IISRESET finalizaba con éxito, tras lo cual, nos encontramos con varios servicios que no arrancaban (NetMsmqActivator, NetPipeActivator, NetTcpActivator), encontrando errores del tipo Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll al intentar arrancar alguno de estos servicios. Un error aparentemente relacionado con el .Net Framework 4, que finalmente conseguimos solucionar, instalando una versión posterior (Microsoft Framework 4.5.2). A la hora de desplegar (Deploy) o de retraer (Retract) una Solución (WSP) de Granja (Farm Solution) en SharePoint, es importante tener claro cómo comprobar el estado final, una operación básica que para quienes no trabajan habitualmente con SharePoint suele generar bastantes dudas. En el presente artículo explicamos de forma básica cómo comprobar el estado de una Solución (WSP) a través de PowerShell, para conocer si está o no correctamente desplegada o retraída. Si lo necesitamos, desde SQL Server es posible conocer la versión Cliente de SQL Server (o la versión del SQL Native Client) utilizada para conectar a SQL Server por un proceso cualquiera, ejecutando una simple consulta sobre una DMV, una información que en algunos casos nos puede resultar de gran utilidad poder obtenerla de una forma tan sencilla. Hace poco encontramos un paquete de SSIS 2005, que planificado para su ejecución diaria en un Job del Agente de SQL Server, no se ejecutaba correctamente. Iniciaba su ejecución, pero las tareas del final de paquete no llegaban a ejecutarse. Finalmente fue un simple problema, originado por la edición de dicho paquete desde una máquina remota con las herramientas de SQL Server 2008 R2 (SSMS), que provocaron un error en el Layout del paquete (The DDS Layout contains an invalid control progid. The layout will be regenerated), y que resolvimos simplemente editando dicho paquete SSIS de nuevo con las herramientas de SQL Server 2005. |
