Muchas veces me preguntaron si era posible redirigir las OU en donde se crean los usuarios y equipos por defecto.
Para que se preguntaran? El ejemplo mas sencillo se ve en que las OU originales no permiten la asignación de políticas de grupo vinculadas directamente a ellas. Y por lo tanto dificultan la aplicación de políticas para provisioning de equipos nuevos.
En caso de que lo quieran probar tengan en cuenta que algunas aplicaciones como Exchange 2000 son sensibles a este tipo de cambios. Por lo que les recomiendo que prueben los cambios en desarrollo previamente. Adicionalmente el dominio deberá estar en modo Windows 2003.
Pero bueno, vamos al grano. La redirección es bastante sencilla, para mover la OU users deberemos ejecutar el comando redirusr seguido del CN de la OU que deseamos utilizar.
en caso de que queramos mover la OU computers deberemos ejecutar el comando redircmp seguido del CN de la OU que deseamos utilizar.
Espero los sea de utilidad.
Saludos
En la semana estuve instalando un servidor de Exchange desde 0 y cuando llego el momento de instalar las actualizaciones note que demoraba mas de lo normal en la recompilación de los assemblies de .NET framework. Luego de esperar cerca de media hora sin suerte y con poco que hacer mas que buscar la causa del problema encontré la solución en los logs del Framework (c:\windows\Microsoft.NET\Framework64\v2.0.50727), aparentemente cuando el proceso de recompilación encuentra un assemblie que ya esta en su ultima versión debería pasarlo por alto y seguir con el siguiente en menos de 1 segundo. Pero en mi caso estaba tardando entre 15 y 20 segundos por chequeo, lo que obviamente estaba demorando la instalación considerablemente. (se puede ver en la fracción del log abajo)
12/29/2008 10:36:21 [5660]: Compiling assembly Microsoft.Exchange.Data.Common, Version=8.0.681.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 ...
12/29/2008 10:36:33 [5660]: Assembly Microsoft.Exchange.Data.Common, Version=8.0.681.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 is up to date.
Realmente tengo que reconocer que fue mas suerte que otra cosa, pero aparentemente el problema esta en el chequeo del CRL (certificate revocation list) que hace el proceso para cada archivo. Y como en mi escenario los servidores no tenían internet obviamente nunca llegaba a la CRL lo que provocaba la demora en cada paquete.
Pero como lo evitamos, eso si es sencillo, simplemente hay que ir a las opciones avanzadas de internet explorer y deshabilitar el chequeo de CRL del publicador, para esto:
Herramientas->opciones de internet –> avanzadas
Buscamos la sección de seguridad y deschequeamos la que dice “Check for publisher’s certificate revocation List”
Espero les sea de utilidad.
saludos