LATAM Team blog

por Ivanov Cepeda

En todo el tiempo que llevo ayudando a clientes premier, he encontrado que los casos que más frecuentemente se presentan, y que cuesta más trabajo identificar, están relacionados con rendimiento (performance) en las aplicaciones web, en algunas ocasiones debido a configuraciones que causan problemas, pero la mayoría de las veces los problemas se deben al código de las aplicaciones.

En este post quiero hacer un corto checklist que pueda servir de guía para revisar problemas comunes de configuración que afectan el performance, y las acciones a tomar para empezar a obtener un diagnóstico que ayude a encontrar la raíz del problema.

Revisar que la aplicación no tenga configuraciones que afecten el rendimiento:

a. Verificar que la aplicación no está configurada en modo de depuración como lo explique en un blog anteriormente.

b. Cuando se trata de una aplicación Web basada en le framework 1.1 verificar que la configuración de la aplicación tiene las configuraciones adecuadas según el hardware que se está utilizando, el KB 811268 ha sido de gran utilidad para muchos clientes que han tenido problemas de performance relacionados con la configuración de .Net 1.1, afortunadamente estos parámetros son afinados automáticamente en la versión 2.0 del framework y en las versiones posteriores.

c. Verificar que todos los módulos de la aplicación están compilados en modo Release.

Si ya estamos seguros que la configuración de nuestra aplicación es la adecuada para un ambiente de producción y continuamos teniendo problemas de rendimiento, es hora de empezar a medir el rendimiento del servidor y de nuestra aplicación con contadores de performance que nos indiquen posibles causas comunes de performance.

a. Para aplicaciones ASP clásicas:

i. Es indispensable revisar los siguientes contadores detenidamente por un espacio de tiempo adecuado que incluya la hora en la que se presenta el problema de rendimiento. Si existe algún indicador que indique algún problema relacionado con el hardware (CPU, Memoria, Disco) es momento de revisar la capacidad del servidor, quizá ya llego a su límite y esta sea la causa.

ii. Si la capacidad del Hardware no es el problema y los contadores ASP/Request Wait Time(milisegundos que espero el ultimo request en el queue) y ASP/Request Queued (cantidad de requests en el queue) son muy altos (más de 10000 milisegundos de espera en el queue, o un queue de más de 300 Requests) se podría llegar a afinar la configuración para mejorar el rendimiento siguiendo el KB 238583, sin embargo es hora de empezar a revisar que tan óptimo es el código para la carga que tiene la aplicación y para ello se puede hacer uso de los 25 tips de ASP para mejorar el rendimiento y el estilo.

b. Para aplicaciones ASP.Net:

i. Es indispensable revisar los siguientes contadores detenidamente por un espacio de tiempo adecuado que incluya la hora en la que se presenta el problema de rendimiento. Si existe algún indicador que indique algún problema relacionado con el hardware (CPU, Memoria, Disco) es momento de revisar la capacidad del servidor, quizá ya llego a su límite y esta sea la causa.

ii. Si tiene problemas relacionados con el GC por favor adicione el contador .Net CLR Memory/# Induced GC, algunos desarrolladores utilizan el método GC.Collect para forzar una recolección de memoria al GC, si esto ocurre muy frecuentemente causa problemas de rendimiento graves en la aplicación debido a que los threads deben detener su ejecución cuando el garbage collector se está ejecutando, este contador debe tener en lo posible un valor de 0 si no es así debe tratar de eliminar del código los llamados a la función GC.Collect, sobre todo en las funciones más utilizadas en la aplicación.

Si ya ha identificado los contadores que identifican el problema, pero ningún cambio en la configuración le ayuda a resolver el inconveniente, y no se trata de un problema de capacidad del hardware es tiempo de concentrarse en la fuente más común de los problemas de performance: el código de la aplicación.

Las herramientas que le pueden ayudar a verificar cualquier problema en el código que degrada el rendimiento son variadas y en muchos casos muy complejas, por lo que necesitara la ayuda de especialistas y toda la colaboración de los desarrolladores del sistema.

La falta de instrumentación en las aplicaciones hace muy difícil el poder medir los tiempos de respuesta de las aplicaciones por lo que se requiere de herramientas intrusivas como depuradores o perfiladores de código para poder realizar un diagnóstico de las causas del problema.

La acción mas sencilla a seguir es la de recolectar dumps de memoria en los momentos en que el problema es más grave, de ser posible recolectar 3 o 4 dumps del proceso en donde se ejecuta la aplicación en un espacio de tiempo corto (2 a 3 minutos). Si su aplicación es ASP clásico puede utilizar DebugDiag tanto para colectar dumps como para hacer un análisis de los mismos, sin embargo para poder revisar detalladamente el proceso deberá hacer uso de un depurador que le permita ver en detalle lo que está sucediendo en el proceso, como Windbg, para un análisis detallado puede acudir a los ingenieros de Soporte en Microsoft quienes estaremos gustosos de ayudarle en la identificación del problema.

Por Guillermo Vargas

Primero que nada debemos destacar que Cluster Shared Volumes es una funcionalidad para utilizar solamente con Windows Server 2008 R2 Hyper-V.  Creación, reproducción y almacenamiento de archivos que no se hayan hecho con el Cluster Shared Volumes, incluyendo cualquier usuario o aplicación con datos almacenados en el directorio ClusterStorage de la unidad del sistema en cada nodo, no serán compatibles y pueden dar lugar a un comportamiento impredecible, incluyendo corrupción de datos o pérdida total de los mismos.

Habiendo hecho ésta aclaración, es de suponer que a esta altura de las circunstancias, probablemente ya ha escuchado acerca de la innovación incorporada al producto Failover Clustering en Windows 2008 R2 y que se conoce con el nombre de “Cluster Shared Volumes” (CSV, por sus siglas en Inglés). CSV funciona como un sistema de archivo de acceso distribuido optimizado para Hyper-V. Una comparación sería un sistema de archivos agrupado, sin embargo, a diferencia de otros sistemas de archivos agrupado, CSV no utiliza cualquier tecnología propietaria – utiliza NTFS estándar, así que no hay nada especial que necesite adquirir o solicitar apoyo – simplemente funciona! Si su almacenamiento de información es adecuada y se la puede definir como una agrupación estándar de discos, entonces puede utilizarse como un volumen de Clúster compartidos. En el pasado, sólo un nodo podía alojar una máquina virtual (VM) y tener acceso al VHD sobre el almacenamiento compartido, así que si otro nodo necesitaba hacerlo, la única manera de hacerlo era mediante un failover que afectaría a todos los recursos en ese disco compartido. Con CSV en R2, cualquier nodo puede alojar la máquina virtual y cualquier nodo pueda tener acceso al VHD en el almacenamiento compartido, por lo que quien quiera que sea el propietario de la máquina virtual y el disco podría circular libremente en los nodos de clúster sin afectar a otros recursos en ese disco compartido.

CSV proporcionará muchas ventajas, incluyendo administración más sencilla de almacenamiento, una mayor resistencia a las fallas, la capacidad de almacenar muchas máquinas virtuales en un único LUN y hacer un failover individualmente; particularmente, CSV proporciona la infraestructura para apoyar y mejorar la migración en vivo de las máquinas virtuales de Hyper-V. En ésta entrada de blog cubriremos la configuración y la implementación de VMs de Hyper-V con CSV en un clúster de failover de Windows Server 2008 R2 y analizaremos otras ventajas y características de CSV para futuras migraciones en vivo.

Preparación del clúster

Para configurar CSV primero debemos construir el clúster. No hay nada diferente que hay que hacer para CSV. R2 clustering trabajará sin problemas con  iSCSI, SCSI (SAS) y Fibre Channel. CSV trabajará con cualquiera de estos, siempre y cuando el disco esté usando NTFS como sistema de archivos.

Para las redes, como ya es sabido, se recomienda disponer de una red pública para las conexiones de clientes y una red de 'heartbeat' para la supervisión de la salud del clúster. Además, se recomienda una red dedicada para el tráfico de migración en vivo y CSV que debe ser al menos 1 GB. Ésto es para asegurar que la red del “heartbeat” no sea inundada de paquetes que provoquen un failover inesperado sin necesidad. Si va a utilizar iSCSI necesitará otra NIC para esa red iSCSI.

Una vez que haya verificado que el hardware que se va a utilizar en el clúster soporta Hyper-V, instale la función Failover Clustering y el papel de Hyper-V  que se encuentra en la ventana del Administrador del Servidor. Debido a la forma en que los discos del CSV son accedidos, se recomienda utilizar la misma letra de unidad donde se encuentra instalado su sistema operativo para cada nodo del clúster (Por ejemplo C:\).

Una vez que el hardware está conectado y se hayan instalado las funciones y papeles correctos, debe asegurarse de que toda la configuración del clúster es soportada. Esto se hace mediante la ejecución de la herramienta de validación de la configuración (Guía: Validación de Hardware para un Clúster de Failover).

Luego de que todos los componentes hayan pasado exitosamente la validación de la herramienta, ya está listo para proceder a crear el Clúster.

Habilitar CSV

Para habilitar los  Clúster de Volúmenes Compartidos (CSV), haga clic en el nombre del clúster en el panel de navegación del administrador de clústeres de conmutación por error. Luego en el panel central, haga clic en el enlace "Habilitar Clúster de Volúmenes Compartidos …". Le aparecerá una notificación recordándole que CSV es sólo para uso con Hyper-V. Con esto ya puede dar por seguro que el clúster es compatible con CSV.

Aparecerá un nuevo nodo en el panel de navegación para  Cluster Shared Volumes:

Crear discos de CSV

Ahora que está habilitado el CSV, es hora de crear algunos discos CSV. 

a) Seleccione el nodo de  Cluster Shared Volumes en el panel de navegación del administrador de clústeres.

b) En el panel derecho de las acciones, seleccione "Add Storage". Aparecerá una ventana que muestra todos los discos en el grupo de almacenamiento disponible. Compruebe los discos que desea agregar y, a continuación, seleccione "OK".

VHD copia a los discos de CSV

CSV permite, a cada nodo de clúster, el acceso al disco al mismo tiempo. Esto se logra mediante la creación de un espacio de nombres común bajo % SystemDrive%\ClusterStorage. Por esta razón, es necesario que el sistema operativo tenga la misma letra de unidad en todos los nodos del clúster (como C:\, utilizado en este artículo). De ésta manera, se verá el mismo directorio en forma consistente en cada nodo del clúster y que dicho sea de paso, es la manera más eficiente de acceder a los discos CSV.  

Cada disco CSV tiene su propio volumen en el directorio y se le asigna el nombre predeterminado, VolumeX, para cada disco. En este ejemplo tenemos 3 discos CSV, por lo que vemos 3 carpetas. El directorio de C:\ClusterStorage debe mantener el mismo nombre, sin embargo, se pueden cambiar el nombre los volúmenes dentro de este directorio.

Tendrá que copiar su VHD en estos directorios para crear máquinas virtuales altamente disponibles. CSV soporta VHDs de expansión dinámica,  tamaño fijo y diferenciación. CSV no es compatible con discos denominados pass-through.

Crear máquinas virtuales en discos CSV

Después de habilitar CSV y colocar los VHDs en los discos CSV, ya estamos listos para presentar esas máquinas virtuales como altamente disponibles.

a) Abra el administrador de Hyper-V

b) En el panel de acciones, seleccione "Nuevo" y, a continuación, "Virtual Machine". Esto abrirá al Asistente para crear una nueva máquina virtual.

c) Proporcione un nombre para la máquina virtual y seleccione el cuadro de verificación "Almacenar la máquina virtual en una ubicación diferente", a continuación, especifique la ruta bajo "C:\ClusterStorage\" para el volumen que desea que la máquina virtual utilice.

d) Especificar la memoria para la máquina virtual, a continuación, "Next >"

e) Especificar la red para la máquina virtual, a continuación, "Next >"

f) En la página conteniendo "Conectar disco duro virtual", cualquiera que se especifique ya sea "Crear un disco duro virtual" o "Uso de un existente disco duro virtual", especifique una ruta apuntando  a la ubicación de  Clúster de Volúmenes Compartidos encontrado en C:\ClusterStorage\

g) Seleccione "siguiente >"

h) Seleccione las opciones deseadas en la página del asistente "Opciones de instalación". Seleccione "siguiente >"

i) Seleccione "Finalizar" en la página de resumen del Asistente.

Haga su CSV de VMs altamente – disponibles

Ahora que hemos creado nuestras VMs en nuestros discos CSV, debemos hacerlos altamente disponibles para que puedan ser administrados por el clúster y puedan hacer el failover.

a) Abra el administrador de clústeres de conmutación por error (Failover Clustering)

b) En el panel izquierdo, seleccione "Servicios y aplicación"

c) En el panel de acciones, seleccione "Configurar un servicio o aplicación". Esto abrirá el asistente de creación "de alta disponibilidad"

d) Seleccione "Virtual Machine" y, a continuación, seleccione "siguiente >"

e) Compruebe la máquina virtual que desea agregar al clúster de conmutación por error. (Tenga en cuenta que la máquina virtual debe estar apagada/desactivada para poder agregarse) Seleccione "siguiente >"

El clúster determinará si éste VM está utilizando CSV o discos de clúster estándar basados en la ruta de acceso del VHD (buscará la ruta %SystemDrive%\ClusterStorage). 

f) Revise la página de confirmación en el asistente y seleccione "siguiente >"

g) Revise la página Resumen en el asistente. Si el Estado no es "Success", revisar el informe seleccionando el botón "Ver informe..." e investigar la información para posibles causas. De lo contrario, seleccione "Finalizar"

Las máquinas virtuales se mostrarán en el panel izquierdo del administrador de clústeres. Automáticamente se les da el nombre de "Virtual Machine" con un número para diferenciarlos. Estos nombres pueden cambiarse haciendo clic con el botón derecho del ratón en ellos y seleccionando "cambiar el nombre".

Inicie sus máquinas virtuales cuando esté listo.

Realizar una migración en Vivo

Ahora tienes el clúster CSV funcionando con ningún hardware especial o consideraciones adicionales. Puede administrar el recurso de máquina virtual como cualquier recurso estándar, tales como el cambio de las propiedades, la creación de dependencias y realizar conmutaciones por error. Se dará cuenta que para las VM ahora puede llevar a cabo una migración en vivo que le permite mover una VM en ejecución de un nodo de clúster a otro nodo del clúster sin ninguna interrupción del cliente. Esto mantiene una máquina virtual altamente disponible incluso cuando la máquina virtual se mueve entre diferentes máquinas físicas.

Para realizar una migración activa, seleccione el botón 'En Vivo migrar esta máquina virtual' y elija un destino en el panel derecho de acciones en el administrador de clústeres de conmutación por error. Esto llevará a cabo la migración en vivo y su estado se indicará en el panel de información del centro.

Usted puede tener CSV sin migración en vivo o puede realizar una migración en vivo sin CSV, sin embargo, estas son tecnologías que se complementan mutuamente que valdrá la pena explorarlos en futuros blogs.

Recursos adicionales

• Source: Deploying Cluster Shared Volumes (CSV) in Windows Server 2008 R2 Failover
• Whitepaper: Windows Server 2008 R2 & Microsoft Hyper-V Server 2008 R2 - Hyper-V Live Migration Overview & Architecture
• Step-by-Step Guide for Hyper-V: Using Live Migration in Windows Server 2008 R2
• Cluster Shared Volumes (CSV): Disk Ownership

por Daniel Seveso

Hemos recibido algunas preguntas de nuestros clientes con respecto a la instalacion del Servce Pack 2 de Exchange 2007 y creímos de utilidad resumir algunas de las más frecuentes y sus respuestas en este artículo. Por favor si tienen consultas relacionadas a la instalación del SP2 que no estén contempladas, envíanos tu comentario.

Q: SP2 Puede instalarse como actualización de SP1 o se instala desde cero?

A: Puedes instalar SP2 directamente en un servidor sin Exchange, o actualizar Exchange 2007 RTM ó SP1 en cualquier nivel de Rollup.

Q: SP2 va a extender el Schema de mi directorio activo?

A: Si. Exchange 2007 SP2 incluye una extensión de Schema necesaria para la interacción con Exchange 2010. Para evitar la actualización del Schema en dos oportunidades, en SP2 se ha incluído la versión completa y definitiva del Schema de Exchange 2010 RTM, por lo que cuando instales Exchange 2010 en tu organización, no habrá una nueva extensión del Schema.

En consecuencia, la cuenta con la que ejecutes el instalador de SP2 deberá pertenecer a los grupos Schema Admins y Enterprise Admins. La máquina dedesde la que está efectuando la actualización del Schema, debe estar en el mismo Site de AD que el controlador de dominio que tiene el rol de Schema Master, además deberá ser Windows 2003 SP2 o superior con Windows Installer 4.5 instalado.

En caso que esta máquina no sea la misma donde se instalará Exchange 2007 SP2, deberás correr el siguiente comando que solamente actualizará el Schema (al igual que en versiones anteriores esta separación durante la instalación te permitirá delegar la ejecución a administradores de AD si es que el administrador de Exchange no tiene los privilegios antes mencionados).

setup /PrepareSchema

Q: Es necesario preparar el dominio de directorio activo?

A: Si. Se instroduce un nuevo grupo de seguridad universal (Universal Security Group) para permitir el mismo nivel de funcionalidad que Exchange 2010 en cuanto a administración remota usando powershell. La creación de este grupo se realiza durante la preparación del dominio. Los requisitos de máquina son los mismos que para PrepareSchema y la cuenta de instalación debe pertenecer al grupo Enterprise Admins. La ejecución de PrepareAD también se puede delegar y ejecutar independientemente de la instalación de SP2 con el siguiente comando:

setup /PrepareAD

Nota: tanto PrepareSchema como PrepareAD ejecutarán automáticamente como parte del setup si el usuario tiene los permisos apropiados para ello.

Q: Configuración regional en los controladores de dominio Windows 2003

A: Exchange SP2, como otros productos (BitLocker, Office Communication Services, etc.) introducen cambios en los índices del schema que el directorio activo no puede crear correctamente si la configuración regional de los controladores de dominio Windows 2003 usan la configuración reguional mencionada en el siguiente artículo. En caso de tener los DCs con esta configuración, recibirás un error 1136 cada 5 minutos en los DCs. El siguiente artículo describe el problema para el caso de BitLocker, que es análogo al problema observado luego de instalar Exchange 2007 SP2.

932862    Error messages after you install the BitLocker Drive Encryption schema updates in a Windows Server 2003 domain

Los atributos afectados en Exchange son los siguientes:

• msExchRoleFlags
• msExchThrottlingIsDefaultPolicy
• msExchLicenseToken
• msExchScopeFlags
• msExchObjectID
• msExchRoleAssignmentFlags
• msExchRoleEntries

Este problema no ocurre en controladores de dominio Windows 2008.

La recomendación más directa es mantener los controladores de dominio Windows 2003 con la configuración regional en inglés. De lo  contrario, puedes implementar el procedimiento mencionado en el artículo para los atributos afectados.

Los eventos no generan ningún problema de funcionamiento en Exchange ni en el directorio activo, sin embargo es un evento que provoca mucho ruido y puede hacer que otros eventos de importancia pasen desapercibidos en el log de eventos.

Q: Cuales son los cambios de Schema que introduce SP2?

A: SP2 modifica clases y atributos existentes, agrega nuevas clases, atributos, indices e identificadores de objetos. Puedes ver la lista completa en este documento de MSDN: Schema Changes Reference for Exchange 2007 SP2

Q: Que versión de Windows Installer requiere la instalación de SP2?

A: Require Windows Installer 4.5. En caso que no esté instalado, el programa de setup te proporcionará el link para instalarlo. También puedes obtenerlo aquí.

Q: Todos mis controladores de dominio son Windows 2008 R2. Necesito tener alguna consideración?

A: Si. Si el servidor donde estas instalando Exchange tiene conectividad a Internet, necesitas actualizar el archivo de prerequisitos cuando el setup lo requiera. Si no tienes conexión a internet, deberás seguir el procedimiento descrito en el siguiente artículo: The fix for installation of Exchange 2007 SP2 with Windows 2008 R2 Domain Controllers is now available.

Q: Debo desinstalar los “Interim Updates” (IU) que tenga instalados?

A: Si. Si tienes algún IU instalado para tu nivel de Service Pack / Rollup Update, deberás desinstalar el Interim Update para instalar SP2.  No es necesario desinstalar Rollup y/o Service Packs previos.

Q: Puedo instlar Exchange 2007 SP2 en Windows 2008 R2?

A: No. Este aspecto ya lo hemos discutido en un post anterior de nuestro blog.

Q: Que versión debería aparecer en el Exchange Management Console y en Exchange Management Shell luego de la actualización o instalación de SP2?

A: En la consola sobre “Server configuration”: Version 8.2 (Build 176.2).  En el Shell obtendrás lo siguiente:

[PS] get-exchangeserver |fl *version*

AdminDisplayVersion : Version 8.2 (Build 176.2)
ExchangeVersion     : 0.1 (8.0.535.0)

Los principales ejecutables como EdgeTransport.exe, Mad.exe y Store.exe van a tener la versión 8.2.176.0.

Q: Donde consigo las notas de instalación de Exchange 2007 SP2?

A: Release Notes for Exchange Server 2007 SP2

Q: Que actualizaciones se incluyen en SP2?

A: What's New in Exchange Server 2007 SP2

Q: Como realizo la actualización en un servidor cluster (Clustered Mailbox Server)?

A: Hay dos artículos que indican como hacerlo: Planning for Cluster Continuous Replication or Single Copy Clusters para la instalación inicial, y Upgrading Clustered Mailbox Servers to Exchange 2007 SP1 or SP2 para instalaciones existentes de Exchange. Esperamos publicar una versión en español o portugués resumiento este procedimiento si el tiempo lo permite.

Q: Cual es el órden recomendado de instalación de SP2 en cada rol de mi organización?

A: El orden recomendado es el siguiente:

• Client Access servers (primero los de Internet, luego los internos)
• Unified Messaging servers
• Hub Transport servers
• Edge Transport servers
• Mailbox servers

Q: No puedo iniciar varios servicios de Exchange luego de actualizar a SP2

A: Puedes encontrar este problema si actualizas una versión RTM previa a RU5 con eventos similares a este en el log de eventos:

Event Type: Error
Event Source: Service Control Manager
Event ID: 7000
Description: The Microsoft Exchange EdgeSync service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion

Este problema afecta a los servicios Managed Code como el Microsoft Exchange Transport, Microsoft Exchange
Mail Submission y Microsoft Exchange Transport Log search.

La solución a este problema está publicada en el siguiente artículo:

944752    Exchange Server 2007 managed code services do not start after you install an update rollup for Exchange Server 2007

Por Luis Ramirez

He visto muchos casos con problemas de desempeño por causa de un mal entendido de cómo emplear estos switch de configuración, razón por la cual decidí escribir este Blog.

Para empezar vamos a aclarar que es Memoria Virtual y Memoria física.

Memoria Virtual vendría siendo una técnica utilizada para sacar provecho y dar la impresión a CADA aplicación que se viene trabajando con memoria continua. La memoria virtual se basa en lo que es un direccionamiento de espacio lineal llamado Virtual Address Space (VAS)

Memoria Física, sería el área en donde VAS estará apuntando y entre mas memoria física se tendría una mayor área para trabajo y por lo tanto menos acceso a disco (mejorando desempeño).

En un ambiente de 32 bits por diseño de ARQUITECTURA se tiene un límite del direccionamiento virtual de 4 GB (No confundir con memoria FISICA). No importa si tienes 512 MB o 8 GB FISICOS, Windows se encargara de emular esto para cada aplicación. Ahora de estos 4 GB virtuales se dividirán en dos para modo usuario (aplicación) y dos para el kernel (sistema operativo)

/3GB

Lo que hace este switch es incrementar el área de direccionamiento virtual (VAS) a 3 GB en modo usuario y decrementar a 1 GB el kernel, esto es recomendado en casos donde se tenga solo una aplicación corriendo y esta no tenga mucha interacción con el sistema operativo, de lo contrario el servidor tendrá un comportamiento extremadamente lento para responder.

/Userva

Es parecido al 3GB pero aquí podemos manualmente configurar el rango entre 2048 y 3072

/PAE

PAE nos permite direccionar fuera del límite de los 4GB. Digamos que si tienes 8 GB físicos, para poder acceder/direccionar entre 4 y 8 tendrías que tener esta opción habilitada en el sistema operativo. Algo importante a notar es que cada sistema operativo y/o hardware tiene una limitación de cuanto soporta.

Estas opciones las puedes encontrar en Windows 2003 bajo boot.ini, en Vista y versiones posteriores bajo BCDEdit.

AWE

Address Windowing Extentions (AWE) es una funcionalidad para indicarle a una aplicación (como SQL Server) que se puede direccionar VAS mas allá de los 4 GB , esto es, si el SISTEMA OPERATIVO reconoce dicha memoria (con la opción PAE) y la aplicación fue compilada para soportar esto.

Es importante asignarle la política local “LOCK PAGES IN MEMORY” a la cuenta corriendo el Servicio si habilitas esta opción.

En ambientes de x64 BITS el VAS es de 8TB y 7TB en IA64, PAE y 3GB son ignorados.

Escenarios que pueden existir

Windows 2003 32 bits corriendo en un procesador de 64 bits

• El VAS de modo usuario será de 2 GB
• AE esta habilitado por default.
• 3GB se pude habilitar pero NO es recomendado.
• AWE seria necesario para manipular mas alla de los 4GB.

Windows 2003 64 bits corriendo aplicación de 32 bits

• el VAS de modo usuario será de 8 TB
• PAE es ignorado
• 3GB es ignorado
• Aplicación puede usar mas de 2 GB si se habilita AWE.

Windows 2003 32 bits corriendo aplicación de 32 bits con 8 GB de memoria, la opción 3GB y AWE habilitado

El sistema operativo asignara 3GB al modo usuario (aplicación) y 1 GB al sistema operativo, no utilizando el resto.

Escenarios que pueden existir en SQL Server

SQL Server de 32 bits corriendo en 32 bits

• VAS será de 4GB.
• PAE puede ser habilitado si el servidor tiene mas de 4 GB y por lo tanto habilitar AWE y “Lock pages in Memory”
• No recomendamos usar 3GB.

SQL Server de 32 bits corriendo en 64 bits

• VAS es de 8TB
• PAE y 3GB son ignorados.
• Habilitar AWE si se usara mas de 4GB.
• “Lock Pages in Memory” deberá ser configurado si se habilita AWE.

SQL Server de 64 bits corriendo en 64 bits

• VAS es de 8TB
• PAE, 3GB y AWE son ignorados.
• Habilitar “Lock Pages in Memory”

En cuestión de SQL Server para hacer uso de más VAS es recomendado

• Tener la opción de /PAE habilitada
• Tener al menos la última versión de actualización de SQL Server.
• Habilitar Address Windowing Extentions (AWE)

sp_configure 'show advanced options', 1

RECONFIGURE

GO

sp_configure 'awe enabled', 1

RECONFIGURE

GO

• Al configurar MAX Server Memory considera dejar 2 GB FISICOS para el sistema operativo y dejar mas memoria por cada instancia corriendo de manera tal que no se saturen.
  
  Por ejemplo, si tienes un servidor con una instancia, 8BG físicos puedes poner a SQL con 6GB (si es que no está corriendo otros servicios)

sp_configure 'max server memory', 6144

RECONFIGURE

GO

Mayor Información

• Memory Limits for Windows Releases
• Physical Address Extension
• Memory Support and Windows Operating Systems
• Enabling AWE Memory for SQL Server
• How to configure SQL Server to use more than 2 GB of physical memory
• SQL Server only uses 2 GB of memory even though the AWE option is enabled
• How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
• Monitoring Memory Usage (2000)
• Monitoring Memory Usage (2008)
• SQL Server memory related performance counters
• Effects of min and max server memory
• AWE enabled Option

Palestrantes: Viviane Lopes e Saulo Cruz

“Nesta sessão iremos explicar o que você deve fazer para estar preparado para inicio do horário de verão em outubro de 2009. A sessão terá 15 minutos de apresentação, seguidas de 45 minutos para Perguntas e Respostas.”

Baixe o Webcast arquivado da MSDN

Disclaimer:  The steps provided in this bulletin were created to mitigate the impacts that the daylight saving time changes may cause for customers in Argentina. These are the impacts primarily anticipated at the time this document was written, and the effects that customers may face are not restricted to them.  The suggested actions on this document might receive additional testing. The information described in this document may change without notice. In addition, customers should be aware that further guidance will be provided at any time by Microsoft.

Special notes: There is no official decree for the DST in Argentina yet, thus the information on this bulletin may change at any time.

Background – Argentina DST 2009/2010         

It is not clear or official as of October 16th 2009, what Argentina will be doing concerning the Daylight Saving time observation for 2009/2010.

In  December 2008, Microsoft implemented a Daylight Saving Time rule for the Windows Operating Systems which contains the following settings for the Argentinean time zone “(GMT -3:00) Buenos Aires”:

• Daylight Saving Time starts at third Saturday of October at 11:59:59PM
• Daylight Saving Time ends at second Saturday of March at 11:59:59PM

This bulletin was written considering 2 possible scenarios, as detailed below:

For provinces that will adopt the Daylight Saving Time in Argentina

There are no special instructions to transition to the daylight saving time (October 18^th, 2009), for the following scenarios:

• Machines that are updated with KB 955839 or KB 970653 available on Windows Update:
   
  
• Machines adjusted according to the guidelines published on the Latam Blog last year.

Important notes:

• If there is a need to update a Windows 2000 machine, customers may follow the procedures detailed in “How to manually update Windows Servers and Desktop Operating Systems” to update their systems as published on the Latam Blog last year.
  
• Do not adjust the machine’s clock manually. This will cause adverse effects on your environment and it is not supported by Microsoft.

For provinces that will NOT adopt the Daylight Saving Time in Argentina

Per information on the Clarin newspaper, some Argentinean provinces will not adopt the daylight saving time as defined by the Federal government back in 2008.

The instruction for provinces that will not observe the DST in Argentina is “un-select” the DST setting "Automatically adjust clock for Daylight Saving Time" as displayed below:

Creating a script to “un-select” the “Automatically adjust clock for Daylight Saving Time” time zone setting on Windows Servers and desktop operating systems:

1. Click Start, click Run, type notepad, and then click OK.
2. Copy the following registry information, and then paste it into the Notepad document:
   
   Windows Registry Editor Version 5.00
   
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
   "DisableAutoDaylightTimeSet"=dword:00000001
   
3. On the File menu, click Save As.
4. Select a destination, and then type DSToff.reg in the File name box. 
5. In the Save as type box, click All Files, and then click Save.
6. Import this registry key on target machines by double clicking in the DSToff.reg and clicking ‘Yes’ when prompted. Execute this registry file in all machines (clients and servers) where you want to “un-select” the “Automatically adjust clock for Daylight Saving Time” setting.
7. In order to deploy these time zone changes in a corporate environment, you can use a startup script as described below.

Deploying DST modifications using Group Policy

1. Click Start, click Run, type notepad, and then press ENTER. 
2. Copy the following code, and then paste it into the Notepad document.
   
   @echo off
   
   regedit /s \\contoso.com\NETLOGON\DSToff.reg
   ver |find /i "6.0">nul
   IF %errorlevel% EQU 0 GOTO end
   
   :end
   
   Note:     You must replace the \\contoso.com notation above with the actual DNS domain name for your Active Directory domain.
   
3. On the File menu, click Save As.
4. DST2009Update.cmd in the File name box. 
5. In the Save as type box, click All Files, and then click Save. 
6. Copy the following files to the Netlogon share folder of the domain controller that holds the PDC emulator role in the domain:
   
   DSTOff.reg 
   DST2009Update.cmd
   
7. Wait until Active Directory replication occurs. Also, wait until the files and folders in the system volume (SYSVOL) shared folder replicate to domain controllers in the domain. 
8. Click Start, click Run, type control admintools, and then click OK. 
9. Double-click Active Directory Users and Computers. 
10. Select an Organizational Unit (OU) which contains the computers that you want to apply this script to. In this example, we will use an OU that is named DST-COMPUTERS. This example also assumes that this OU contains computer accounts.
11. Right-click the DST-COMPUTERS OU and then click Properties. 
12. Click the Group Policy tab, click New, type DST Registry Update, and then press ENTER. 
13. Click Edit. The Group Policy Object Editor tool starts.
14. Expand Computer Configuration, expand Windows Settings, and then click Scripts (Startup/Shutdown). 
15. Double-click Startup, and then click Add. 
16. In the Script Name box, type the universal naming convention (UNC) path of the DST2009Update.cmd file that is located in the Netlogon share. For example, type \\contoso.com\NETLOGON\DST2009Update.cmd. 
17. Click OK two times. 

Note:     Client computers that are within the DST-COMPUTERS organizational unit will run the startup script the next time the machine starts up, meaning all machines needs to be restarted to be able to recognize the new DST configuration via Startup script.

Important information about procedures described in this section:

• The instructions above can be applied on Windows 2000, Windows XP and Windows Server 2003 Operating systems. You may need to restart the machine for the changes to take effect.
  
• The instructions above should not be used on Windows Vista or Windows Server 2008 operating systems. On these operating systems, please uncheck the “Automatically adjust clock for Daylight Saving Time” manually.

Impacts for Outlook clients and Exchange Servers

Please verify which of the options applies to your environment to determine the impact for Outlook clients and Exchange Servers:

For customers who will not perform any modification on their current time zone configuration, we do not foresee any impact on the Outlook client and Exchange Server.

As a precautionary measure, we do recommend users to print their calendars before the start of the Daylight Saving time on Sunday, October 18th 2009, so they can have a printed reference.

Any modification on the operating system time zone configuration, such as un-selecting the checkbox "Automatically Adjust clock for Daylight Saving Time" will cause appointments on the Outlook client to be one hour off.

The appointments affected will likely be the ones created prior to any time zone change, which occur between October 18^th 2009 and March 13^th 2010.

Example of users who may experience issues with their Outlook calendar:

• Users located in a province which adopted Daylight Saving Time in 2008, but will not observe a Daylight Saving Time in 2009.  Users in this province should “un-select” the DST setting “Automatically adjust clock for Daylight Saving Time” for the “(GMT -03:00) Buenos Aires” time zone.

What can I do to fix appointments affected by DST changes?

In case your Outlook calendar is affected by the DST changes, please manually modify each appointment on the affected months after the operating system time zone has been changed. 

We recommend you to print your calendar before any changes are made, and then review the calendar items to make sure these items appear at the correct times. You can use this printed copy of the calendar items as a reference.

How to manually modify Outlook calendar items?

1. Start Outlook, and then open the Outlook calendar.
2. Manually move each meeting that you organized so that they occur at the correct time. 
3. Send an update for each meeting that you moved to the meeting attendees. This action causes the calendar for each attendee to display the correct time for the meeting. 
4. Manually move each single-instance appointment.
5. Manually move all recurring appointments affected by the changes. 

How to the Outlook issue could have been avoided?

• Any change in the time zone for a country should be announced to the local companies months in advance prior to the change. This would give time for users and administrators to adapt to the new rules and would prevent users from creating appointments using the wrong time zone settings.
  
• The provinces not following/adopting DST in Argentina this year should have communicated this decision at the end of the last DST period.

By: Daniel Aguiar / Technical Reviewer: Mauricio Rincon

O nosso colega Jie Li escreveu recentemente um post muito interessante sobre como atualizar o SharePoint para a versão de Service Pack e Hotfix, mais recente.
Como o post está em inglês nos aproveitamos o ótimo trabalho e o traduzimos para português.

Atualização acumulativa de Junho para SharePoint

As atualizações acumulativas para Microsoft Office SharePoint Server 2007 e Windows SharePoint Services 3.0 estão prontas para serem baixadas:

Os links para download são

• Windows SharePoint Services 3.0 June cumulative update package
• Office SharePoint Server 2007 June cumulative update package

Descrições detalhadas sobre os pacotes

• Description of the Windows SharePoint Services 3.0 June cumulative update package
• Description of the Office SharePoint Server 2007 June cumulative update package

Algumas recomendações para novas instalações de servidores SharePoint

Para manter todos do SharePoint atualizados, faça a seguinte seqüência de instalações:

1. Service Pack 2 para o Windows SharePoint Services 3.0 e os Language Packs necessários
2. Service Pack 2 para o Office SharePoint Server 2007 e os Language Packs necessários
3. Instalar em seguida o Bugfix 971620 (Este hotfix corrige a versão do SharePoint que pode ser alterada na instalação do Service Pack 2)
4. Atualização acumulativa de Junho para Windows SharePoint Services 3.0
5. Atualização acumulativa de Junho para Office SharePoint Server 2007

Observação: Inicie a partir da atualização acumulativa de abril. Os pacotes não irão instalar em uma farm sem Service Pack instalado. Você precisa instalar o Service Pack 1 ou Service Pack 2 antes das atualizações acumulativas.

Após aplicar as atualizações, execute o "SharePoint Products and Technologies Configuration Wizard" ou então execute o comando “psconfig –cmd upgrade –inplace b2b -wait”. Esse passo precisa ser feito em todos os servidores SharePoint presentes na Farm.

A versão do Content Databases devera ser 12.0.6510.5000 após aplicar com sucesso as atualizações.

Jie Li, Technical Product Manager, SharePoint
Published Monday, July 20, 2009 1:21 PM by sptblog
Link para o original: http://blogs.msdn.com/sharepoint/archive/2009/07/20/june-cumulative-update-packages-ready-for-download.aspx

Por: Rafael Ortega / Revisión Técnica: Mauricio Rincon

Nuestro colega Jie Li escribió recientemente un post muy interesante sobre como actualizar Sharepoint para la versión y Hotfix mas reciente.
Esta es una traducción al español de este artículo.

Actualización acumulativa de Junio con los paquetes de actualización listos para su descarga

Los paquetes de actualización de la actualización acumulativa para el Servidor de Microsoft Office SharePoint 2007 y Windows SharePoint Services 3.0 están listos para ser descargados. Los artículos de la base de conocimiento también están disponibles.

Información de descarga

• Paquete de actualización acumulativa de Windows SharePoint Services 3.0 de Junio
• Paquete de actualización acumulativa para Office Sharepoint Server 2007 de Junio

Descripción detallada sobre los paquetes

• Descripción del paquete de actualización acumulativa para Windows Sharepoint Services 3.0 de Junio
• Descripción del paquete de actualización acumulativa para Sharepoint Server 2007 de Junio

Instalación recomendada para un Servidor nuevo de Sharepoint

Para mantener todos los archivos de instalación de Sharepoint actualizados, la siguiente secuencia es recomendada.

1. Service Pack 2 para Windows Sharepoint Services 3.0 y paquetes de lenguajes
2. Service Pack para Office Sharepoint Server 2007 y paquetes de lenguajes
3. Fix 971620 (que fue el fix para arreglar el problema de las pruebas, este fix estará incluido en la siguiente ronda de actualizaciones acumulativas)
4. Paquete de Actualización acumulativa de Junio para Windows Sharepoint Services 3.0
5. Paquete de Actualización Acumulativa de Junio para Office Sharepoint Server 2007

Tenga cuidado: A partir de la actualización acumulativa de Abril, los paquetes no se instalaran en una granja sin un service pack instalado. Debe tener instalados cualquiera de los dos Service Pack 1 (SP1) o SP2 antes de instalar las actualizaciones acumulativas.

Después de aplicar las actualizaciones, ejecute el asistente de configuración de SharePoint, o ejecute el comando de “psconfig –cmd upgrade –inplace b2b -wait” en la línea de comandos. Esto necesita hacerse en cada servidor en la granja con SharePoint instalado.

La versión del contenido de la base de datos debe quedar en 12.0.6510.5000 después de aplicar exitosamente estas actualizaciones.

Usted también puede referirse al post de actualizaciones acumulativas de Abril para guías de implementación, “Preguntas Frecuentes” y “Como hacerlo”.

Jie Li, Technical Product Manager, Sharepoint
Publicado el Lunes 20 de Julio 2009
El link del artículo original: http://blogs.msdn.com/sharepoint/archive/2009/07/20/june-cumulative-update-packages-ready-for-download.aspx

CENÁRIO – HORÁRIO DE VERÃO BRASIL 2009/2010

Para o ano 2009/2010, o horário de verão no Brasil determinado pelo governo Brasileiro é como a seguir:

• Horário de Verão inicia no terceiro Domingo de Outubro à 00:00:00.
• Horário de Verão termina no terceiro Domingo de Fevereiro à 00:00:00.

No último ano a Microsoft atualizou as regras do horário de verão para os fusos horários Brasileiros - (GMT -3:00) Brasilia e (GMT -4:00) Manaus, no sistema operacional Windows, com os seguintes parâmetros:

• Horário de Verão inicia no terceiro Sábado de Outubro às 23:59:59
• Horário de Verão termina no Segundo Sábado de Fevereiro às 23:59:59

Em 2009, o dia seguinte ao “Segundo Sábado de Fevereiro” correspondeu ao “Terceiro Domingo de Fevereiro”, assim sendo, a regra para o fuso horário no Sistema Operacional Windows correspondeu com as datas definidas pelo governo Brasileiro:

Todavia, em 2010, o dia seguinte ao “Segundo Sábado de Fevereiro” corresponde ao “Segundo Domingo de Fevereiro”. Isto significa que o fuso horário correntemente definido no sistema operacional Windows está defasado das datas definidas pelo governo Basileiro em uma semana.

Devido a diferença explicada acima, o sistema operacional Windows não interpretará corretamente a hora relacionada ao fim do horário de verão no Brasil em 2010 (21 de Fevereiro as 00:00).

Adicionalmente, na semana de “14 – 20 de Fevereiro, 2010”, os usuários do Exchange e Outlook poderão experimentar discrepâncias no calendário – uma vez que o sistema operacional esteja ajustado, compromissos criados durante esta semana podem estar defasados em uma hora.

RECOMENDAÇÕES PARA USUÁRIOS WINDOWS – INíCIO DO HORÁRIO DE VERÃO BRASILEIRO

Não existem instruções especiais para transicionar ao início do horário de verão (18 de Outubro , 2009) para os seguintes cenários:

• Máquinas que estejam atualizadas com KB 955839 ou KB 970653 disponíveis através do “Windows Update”:

• Máquinas ajustadas de acordo com as instruções publicadas no ano passado no blog do Latam.

INFORMAÇÕES ADICIONAIS – FIM DO HORÁRIO DE VERÃO BRASILEIRO

Usuários deverão seguir instruções adicionais para que estejam preparados para transição ao final do horário de verão em 21 de Fevereiro de 2010. A Microsoft prevê para Dezembro de 2009, o lançamento de uma nova atualização cumulativa para o fuso horário (time zone), contendo as mudanças necessárias para o ajuste relacionado ao fim do horário de verão Brasileiro. Quando esta atualização cumulativa para fuso horário (time zone) for lançada, serão também disponibilizadas diretrizes/instruções para Windows, Exchange and Outlook.

por Fernando Padilla

Para que nuestro dispositivo móvil pueda sincronizar con Exchange (2003/2007) usando ActiveSync necesita establecer necesariamente una comunicación encriptada con el servidor. Esto asegura la confidencialidad de la información transmitida. Cuando el servidor de ActiveSync utiliza un certificado comercial, normalmente nuestro Windows Mobile no requiere de ningún certificado adicional, dado que el sistema operativo contiene los certificados de las autoridades certificadoras (CA) comerciales más populares. En caso que utilices una CA propia instalada en tu empresa o una CA cuyo certificado no haya sido preinstalado en el dispositivo, tendrás que instalar el certificado apropiado antes de que puedas conectarte a ActiveSync.

La práctica diaria de instalar un certificado en una PC, es fácil pues el certificado puede ser transferido al equipo muy fácilmente (E-mail, network share, USB , importado del store donde se ubica, etc.) .

El primer reto que enfrentamos al instalar el certificado obtenido del CA a un dispositivo con Windows Mobile , es el de copiar el propio archivo al dispositivo. Para eso, tenemos que buscar una manera fácil y efectiva de hacerlo (ActiveSync, Flash Memory Card, Bluetooth, Infrarojo, E-mail como Hotmail, Network Share, etc.).

En Windows Mobile 6

Podemos importar certificados Raíz (Root) o certificados personales. Los certificados Raíz (Root) requieren estar en formato PEM (Texto , codificado en Base64) o formato DER (Binario) . Los archivos de certificados Raíz (Root) tienen la extensión .cer o .p7b y pueden contener un solo certificado o toda la cadena de certificados PKCS#7 .

Los certificados personales necesitan estar en en formato PKCS#12 y tener la extensión .pfx o .p12 . Los archivos PKCS#12 , usualmente, contienen un certificado personal y su llave privada correspondiente, un certificado Raíz (Root) , y opcionalmente, certificados CA intermedios.

Nota: para ActiveSync no es necesario instalar un certificado personal, solo el certificado Raíz y si es necesario los certificados intermedios de la cadena.

De esta manera, podrás importar un archivo que contenga uno o más certificados al dispositivo con Windows Mobile:

• Copia el archivo del certificado a tu dispositivo de Windows Mobile 6 , puedes usar varios métodos para transferirlo: ActiveSync , una memoria Flash , Bluetooth, Infrarojo, etc.
  
• Toca “Start”, “Programas” y “File Explorer” .
  
• Selecciona el archivo de certificado que deseas importar (En el File Explorer , no se muestran las extensiones de los archivos, así de que asegúrate de seleccionar el archivo correcto, por ejemplo, confirmando el tamaño del archivo.

• Para importar archivos de certificados Raíz (Root) , no se requiere Password. Para los certificados encriptados en archivos PKCS#12 , necesitarás ingresar el Password.
  
• El certificado(s) incluído en el archivo , se importará , dando el mensaje: “Uno o mas certificados fueron instalados exitosamente” Si ya existe un certificado con el mismo nombre en tu dispositivo con Windows Mobile, será reemplazando silenciosamente, por lo tanto, asegúrate de darle doble click al archivo correcto.

• Cierra el File Explorer.

Para ver los certificados que han sido importados en tu dispositivo con Windows Mobile:

• En el menú de Settings, dale click a la pestaña System, enseguida dale click a Certificados.
  
• Selecciona la pestaña Personal, y se mostrará el siguiente texto: “Usa certificados personales para identificarte con los demás”
  
• Si importaste un archivo PKCS#12 , se debe de mostrar el más reciente certificado añadido. Si le das click a este certificado, debes de ver sus detalles. Click OK para regresar a la ventana anterior.
  
• Dale click a la pestaña “Root”. Debes de ver el reciente certificado raíz que añadiste. Si le das click al nombre de este certificado, debes de ver sus detalles.

Nuestra última tarea es configurar ActiveSync en el dispositivo para sincronizar con nuestro Servidor de Exchange :

Dispositivos con Windows Mobile 5

En dispositivos con Windows Mobile 5 , muchas de las veces, la política de seguridad bloquea el instalador de certificados evitando instalarlos correctamente, por lo que tienes que hacerlo siguiendo estos pasos:

• Descarga la herramienta SmartPhoneAddCert.exe a tu computadora, del sitio Microsoft Download Center:
  Download the SmartPhoneAddCert.exe package now
  
• Ejecuta el SmartPhoneAddCert.exe para extraer el contenido en un folder de tu computadora.
  
• Copia el SmartPhoneAddCert.exe a tu dispositivo móvil.
  
• En tu dispositivo móvil, crea un folder que se llame “Storage” . El programa SmartPhoneAddCert.exe busca el certificado en éste folder.
  
• Copia el certificado raíz (.cer file) al folder Storage en tu dispositivo móvil.
  
• Ejecuta el SmartPhoneAddCert.exe. Dale click al archivo .cer que copiaste al folder Storage, y enseguida instala el Certificado Raíz.

Referencias

• How to install root certificates on a Windows Mobile-based device
• How to add root certificates to Windows Mobile 2003 Smartphone and to Windows Mobile 2002 Smartphone
• Mobile Device Security and Exchange 2007
• Install SSL Certificates on a Windows Mobile Powered Device
• Security Model for Windows Mobile 5.0 and Windows Mobile 6

por Daniel Seveso

Introducción

Cuando configuramos un conector de SMTP (“SMTP Connector” en Exchange 2003 o “Send Connector” en Exchange 2007) uno de los parámetros a definir es como serán entregados los mensajes que pasen por este conector.

En Exchange 2003, esta opción se define en el tab General de las propiedades del SMTP Connector:

En Exchange 2007, se define en el tab Network del Send Connector:

Estas opciones nos permiten definir si el/los bridgehead/s a cargo de este conector utilizarán DNS para resolver el próximo salto del mensaje, o utilizarán un “Smart Host” (también conocido como “Relay Host”).

Entrega por DNS

Si utilizamos DNS, no hay ningún misterio: A grandes razgos, el servidor bridgehead inspecciona el mensaje a entregar, extrae el dominio de su destinatario (parte a la derecha del @ por ej: folk@contoso.com) y consulta por un registro MX “contoso.com” al servidor DNS.  El servidor DNS responderá con una lista de 1 o varios registros tipo A con su respectiva dirección IP de cada servidor smtp recibiendo mensajes para el dominio contoso.com. Nuestro bridgehead entonces se conectará a una de ellas dependiendo de varios factores como disponibilidad, peso de cada una, etc.

Entrega por Smart Hosts

Este es el punto que veremos en detalle: “Forward all mail through this connector to the following smart hosts” en Exchange 2003 y “Route mail through the following smart hosts” en Exchange 2007.

Esta opción nos permite configurar el conector para que entrege los mensajes a un tercero, quien se hará cargo de su ruteo a destino final.  Esta configuración se usa habiltualmente para enviar todos los mensajes a través de un Anti Virus, o para enviar los mensajes a un servidor de borde cuando nuestro servidor no tiene acceso directo a Internet.

Al configurar el relay host podemos especificar su dirección IP o su nombre completo (FQDN por Fully Qualified Domain Name), por lo que es importante entender como se resuelve ese valor en cada caso.

Cuando especificamos su dirección IP el servidor realizará una conexión directa a la misma, evitando la resolución DNS.

Nota: En Exchange 2003 tenemos que especificar la dirección o direcciones IP entre parentesis rectos por ej: “[192.168.31.1]” o “[192.168.31.1; 192.168.31.2]”

Cuando especificamos el nombre completo FQDN el servidor resolverá este nombre a una dirección IP de la siguiente forma:

1. Consulta al DNS por un registro MX
2. Si no obtiene respuesta útil, consultará al DNS por un registro A

Este dato, que actualmente no está explícitamente documentado, es de utilidad cuando realizamos seguimientos de problemas de entrega de mensajes a un grupo de Smart Hosts.

Para configurar entrega de mensajes a un grupo de Smart Hosts, podemos usar diferentes mecanismos de balanceo de carga. El primero y más intuitivo es configurar más de un Smart Host en la configuración del conector, quien se encargará de balancear la carga dispensada a cada uno. La resolución de nombres en este caso, sigue el mismo principio mencionado anteriormente. Supongamos que configuramos 2 Smart Hosts smarthost1.domain.com y smartnost2.domain.com, la resolución de sus nombres a direcciones IP sería :

• Consulta al DNS por un registro MX “smarthost1.domain.com”
• Consulta al DNS por un registro MX “smarthost2.domain.com”
• Si no obtiene respuesta para el MX “smarthost1.domain.com”, consulta al DNS por un registro A “smarthost1.domain.com”
• Si no obtiene respuesta para el MX “smarthost2.domain.com”, consulta al DNS por un registro A “smarthost2.domain.com”

Otra forma es configurar el conector con un sólo Smart Host “balanceado”, utilizando alguno de los siguientes mecanismos: NLB (Network Load Balancing), HLB (Hardware LB), un grupo de registros A con un único nombre (caso en el que DNS realiza una asignación Round Robin de la resolución), o un registro MX conteniendo un grupo de registros A con sus pesos específicos.

Uno sólo de los mecanismo mencionados es suficiente para balancear la carga de entrega de mensajes.

Como averiguar que mecanismos de resolución estamos utilizando

Sea cual sea el mecanismo de balanceo de carga que utilicemos el principio de resolución de nombres por parte del Bridgehead server no cambia, por lo tanto, es útil saber qué mecanismo de resolución estamos utilizando realmente. Si registros MX o registros A, y a partir de este dato poder verificar la configuración de DNS.

Lo más fácil es utilizar NSLookup.exe

Conectado al servidor que oficia de Bridgehead averiguamos la dirección de los DNS que utiliza:

C:\>ipconfig /all

….

DNS Servers . . . . . . . . . . . : 192.168.31.160
                                    192.168.31.161
                                    192.168.31.162

….

Ejecutamos nslookup y realizamos el mismo procedimiento para los (3 en este caso) servidores DNS

C:\>nslookup

> server 192.168.31.160
Default Server: <nombre de tu servidor DNS>
Address: 192.168.31.160

Configuramos el tipo de registro a consultar como “MX” y consultamos por el nombre del Smart Host

> set type=MX

> smarthost1.domain.com.
Default Server: <nombre de tu servidor DNS>
Address: 192.168.31.160

En caso que no encuentre un registro MX, te dara un mensaje “Unknown can’t find smarthost1.domain.com: Non-existent domain” o una referencia a quien es el SOA (Start of Authority) de la zona domain.com o smarthost1.domain.com como el siguiente:

smarthost1.domain.com
        primary name server = dns1.domain.com
        responsible mail addr = admin
        serial  = 2416123
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

Si encuentra el registro MX mostrará algo similar a:

smarthost1.domain.com      MX preference = 10, mail exchanger = smtp1.smarthost1.domain.com
smarthost1.domain.com      MX preference = 10, mail exchanger = smtp2.smarthost1.domain.com
smtp1.smarthost1.domain.com      internet address = 192.168.31.89
smtp2.smarthost1.domain.com      internet address = 192.168.31.90

Aqui sabes que el Bridgehead resolverá por MX a las direcciones 192.168.31.89 y 192.168.31.90

Si no encuentra un registro MX, preguntamos por un registro A:

> set type=A

> smarthost1.domain.com.
Default Server: <nombre de tu servidor DNS>
Address: 192.168.31.160

Name:     smarthost1.domain.com
Address:     192.168.131.91

Aqui sabes que el Bridgehead resolverá smarthost1.domain.com resolverá a la dirección ip 192.168.131.91

Deberás realizar este procedimiento para cada servidor DNS configurado en tu bridgehead y consultar por cada FQDN en el Smart Host para confirmar si la configración de cada DNS es correcta.

Referencias

• Send Connector Properties > Network Tab
• Exchange 2003 Transport and Routing Guide
• 251951 Exchange System Manager Does Not Verify Smart Host DNS Names
• 319426 How To Configure the SMTP Connector to Link to Internet Domains in Exchange
• 294736 When to create SMTP connectors in Exchange 2000 and later
• 257426    XCON: Configuring Exchange 2000 to Use a Smart Host IP Address
  

por Daniel Seveso

Con la salida del nuevo sistema operativo de server Windows 2008 R2 han habido varias consultas en cuanto a su interacción con Exchange. A esto se suma el anuncio de disponibilidad de Exchange 2010 RC para su evaluación y nuevamente, preguntas sobre su coexistencia con Exchange 2007 y Windows 2008 R2.

Lo cierto es que hay varios requisitos que se contraponen si uno quiere probar todo junto, por lo que trataré rápidamente de proveer la información que necesitas para evitar frustraciones al momento de la instalación:

Exchange 2007 en Windows 2008 R2

Comienzo aclarando que Windows Server 2008 R2 es una nueva versión de sistema operativo, no un upgrade o service pack a la version Windows 2008 existente. Esta aclaración sirve para entender mejor los requerimientos que siguen.

Exchange 2007, SP1 o SP2 *no* son compatibles con Windows 2008 R2. Esto quiere decir simplemente que no puedes instalar Exchangen 2007 en un computador que corra Windows 2008 R2 32, ni 64-bit.

Por más información puedes consultar el Exchange Server Supportability Matrix.

Exchange 2007 SP2 en Active Directory con DCs corriendo Windows 2008 R2

Si instalas Exchange 2007 SP2 en Windows 2008 o Windows 2003 64-bit y en tu ambiente sólo tienes domain controllers corriendo Windows 2008 R2, podrás tener un problema de Pre-requisitos que evitará la instalación de Exchange con el siguiente error:

[ERROR] Cannot find at least one domain controller running Windows Server 2003 Service Pack 1 or later in domain 'DC=DCName,DC=com,DC=DCName'. This could be the result of moving domain controller objects in Active Directory. Check that at least one domain controller running Windows Server 2003 Service Pack 1 or later is located in the 'Domain Controllers' organizational unit (OU) and rerun setup

El 16/09/09 Microsoft publicó una actualización que el programa setup actualizará automáticamente si el servidor donde estás instalando Exchange 2007 SP2 está conectado a Internet. Esta actualización corrige un problema en la lista de prerequisitos permitiendo la instalación de Exchange 2007 SP2 en los ambientes previamente mencionados.

En caso que tu servidor no tenga acceso a internet, puedes encontrar los archivos individuales y el procedimiento para su reemplazo en el blog del equipo de Exchange.

Exchange 2010 RC en Windows R2 y coexistencia con versiones anteriores de Exchange

Exchange 2010 RC puede ser instalado en Windows 2008 R2 o Windows 2008 SP2.

Si planeas instalar un ambiente de coexistencia con versiones anteriores, Exchange 2010 RC puede coexistir en la misma organización con Exchange 2007 SP2 y Exchange 2003 SP2 como mínimo.

Nota: Las versiones de productos previos a su liberación ("pre-released" como por ej. Release Candidate RC), son publicados con el propósito de investigación, planificación, realimentación al grupo de producto y entrenamiento. No son oficialmente soportados por Microsoft y no deben ser instalados en ambientes de producción.

Escríbenos si queda alguna duda al respecto!

Por Guillermo Vargas

Cómo configurar el Escritorio remoto y el Terminal Services Gateway.

Escritorio remoto permite a los usuarios controlar su equipo de escritorio en forma remota. Se trata de un concepto simple, que implementándolo correctamente, puede tener un impacto considerable en la productividad de su organización, facilitando que el personal de la empresa pueda trabajar desde sus casas, inclusive sin tener un equipo móvil.

Hasta la aparición de Microsoft Windows Server 2008, la conexión a la red interna ha sido el mayor desafío. La red privada probablemente utiliza direcciones de Protocolo de Internet privadas, que impiden que los usuarios se conecten directamente a sus equipos de escritorio desde el Internet. Aun si se les ofreciera a los usuarios una conexión de red privada virtual, muchos firewalls bloquean VPN.

Para sobrepasar estos límites, Windows Server 2008 presenta el rol de Terminal Services Gateway (TSG), que actúa como un servidor proxy entre el Internet y su red interna. Como se ilustra a continuación, el cliente de escritorio remoto, utiliza un Protocolo de transferencia de hipertexto cifrado sobre Secure Sockets Layer para comunicarse con la puerta de enlace de TS. Porque HTTPS se utiliza principalmente para navegar por el Internet, casi todos los servidores de seguridad lo permiten. La puerta de enlace de TS autentica al usuario (por medio de una contraseña o una tarjeta inteligente), y verifica que el usuario esté autorizado para conectar con el equipo de destino y, seguidamente, utiliza el Protocolo de Escritorio Remoto (RDP) para completar la conexión a la red privada.

Nota: A lo largo de este artículo, se hará referencia como un “Servidor de escritorio remoto” a cualquier equipo que tenga habilitado el RDP. El “servidor de escritorio remoto” podría ser cualquier equipo con Windows XP, Windows Server 2003, Windows Vista, Windows 7 o Windows Server 2008 que tenga habilitado Escritorio remoto. También podría ser cualquier versión de Terminal Server.

Planificación de su certificado SSL de Terminal Services Gateway

Debido a que los clientes utilizan HTTPS para conectarse a la puerta de enlace (Gateway) de TS, la puerta de enlace (Gateway) de TS necesitará un certificado SSL, sería lo mismo que un servidor de Web de comercio electrónico. Para simplificar la configuración de los clientes de escritorio remoto, adquiera un certificado SSL de una de las tantas autoridades públicas de emisión de certificados de confianza (CA) que Windows autoriza predeterminadamente. Al configurar el certificado SSL, especifique el nombre de host completo que los clientes van a utilizan para conectarse a la puerta de enlace de TS desde el Internet. Si el nombre del host no coincide con lo que los usuarios introduzcan en el cliente de escritorio remoto, se producirá un error en la autenticación de servidor.

Aunque se puede utilizar un certificado SSL temporal o interno para propósitos de prueba, los clientes deben confiar en el certificado emitido por el CA. Porque muchos escenarios de acceso remoto implican equipos que no son miembros de su dominio de Active Directory (como ordenadores domésticos), sólo los certificados SSL emitidos por entidades públicas de confianza trabajarán de forma predeterminada.

Nota: Para propósitos de prueba, el Asistente para Agregar Funciones puede generar un certificado SSL temporal para usted. Luego, debe importar el certificado de CA raíz que se genera a los equipos del cliente, para eso, haga clic en el botón de “Certificados” en la ficha contenido del cuadro de diálogo “Opciones de Internet” y, a continuación, importe el certificado a la lista de Trusted Root Certification Authorities.

Configuración de la Terminal Services Gateway

Para agregar la función de servicios de Terminal Server para Windows Server 2008, siga estos pasos:

1. Inicie una sesión como administrador en el equipo de Windows Server 2008. Haga clic en Inicio y, a continuación, haga clic en Administrador de servidores.
   
2. Haga clic con el botón secundario del mouse en funciones y, a continuación, haga clic en Agregar funciones.
   Aquí aparecerá el asistente para agregar funciones de servicios.
   
3. En la página de “Antes de comenzar”, hacer clic en siguiente.
   
4. En la página Seleccionar Funciones del Servidor, seleccione Servicios de Terminal Server. A continuación, haga clic en siguiente.
5. En la página de servicios de Terminal Server, haga clic en siguiente.
   
6. En la página de servicios de función, seleccione TS Gateway. Cuando se le solicite, haga clic en Agregar función de servicios requeridos. A continuación, haga clic en siguiente.
   
7. En la página de certificado de autenticación de servidor, seleccione un certificado SSL y, a continuación, haga clic en siguiente.
   
8. En la página de las directivas de autorización, haga clic en ahora y, a continuación, haga clic en siguiente.
   
9. En la página de grupos de usuarios de TS Gateway, haga clic en Agregar para seleccionar los grupos de usuarios que pueden conectarse a través de la puerta de enlace de terminal server. Normalmente, debe crear un grupo de seguridad de Active Directory para los usuarios de escritorio remoto, que se conectan desde el Internet y agregar todos los usuarios autorizados a ese grupo. A continuación, haga clic en siguiente.
   
10. En la página de TS CAP, introduzca un nombre para la política de autorización de conexión a Terminal Server y elija si desea permitir la autenticación mediante contraseñas, tarjetas inteligentes o ambos. Haga clic en siguiente.
    
11. En la página de TS RAP, introduzca un nombre para la política de autorización de recursos de Terminal Services. A continuación, elija si desea permitir que los clientes remotos para conectarse a todos los equipos de la red interna o sólo los equipos de un grupo de dominio específico. Para obtener mejores resultados, cree un grupo de seguridad de Active Directory y agregar las cuentas de equipo para todos los servidores de escritorio remoto autorizados a ese grupo. Haga clic en siguiente.
    
    Nota: El CAP define quién puede conectar a la puerta de enlace de TS, mientras que el RAP define los equipos que pueden utilizar la puerta de enlace para acceder. Ambos deben definirse para que un usuario pueda establecer una conexión.
    
12. Complete cualquier otra página del asistente que aparecen para funciones dependientes aceptando la configuración predeterminada y, a continuación, haga clic en instalar en la página de confirmación.
    
13. Una vez finalizada la instalación, haga clic en Cerrar y, a continuación, haga clic en sí para reiniciar el equipo si es necesario.
    
14. Después de reiniciar el equipo, iniciar otra sesión y haga clic en Cerrar en la reanudación del Asistente para la instalación.

Más tarde, puede utilizar la consola del administrador del servidor para modificar el CAP o RAP haciendo clic en el nodo correspondiente a roles\terminal services\ts puerta de enlace manager\computer_name\policies.

Si es necesario, configure el firewall para permitir conexiones HTTPS entrantes a su puerta de enlace de TS en el puerto TCP 443. Además, la puerta de enlace de TS debe ser capaz de comunicarse a servidores de escritorio remoto mediante el puerto TCP 3389.

Configurar al cliente de escritorio remoto

Usted debe configurar al cliente de escritorio remoto con la dirección IP de la puerta de enlace de TS antes de conectar a un servidor de escritorio remoto que este en la red interna. Para configurar al cliente de escritorio remoto, siga estos pasos:

1. Si el equipo cliente está ejecutando Windows XP con Service Pack 1 o Windows Server 2003 con Service Pack 1 o 2, instale el cliente de servicios de Terminal Server 6.0. Puede descargar el software desde el siguiente link support.microsoft.com/kb/925876. Windows Vista y Server 2008 ya vienen con el cliente incluido. Las versiones anteriores de Windows no pueden usar el nuevo servicio de Cliente de Terminal Server y, por lo tanto, no se pueden conectar a través de una puerta de enlace de TS.
   
2. Abra “Conexión a Escritorio Remoto” desde el menú Inicio.
   
3. Si es necesario, haga clic en el botón de Opciones para mostrar las opciones de conexión a escritorio remoto.
   
4. En la ficha General, escriba el nombre del servidor de escritorio remoto o la dirección IP (no la puerta de enlace de TS), inclusive si la dirección IP es privado y no se la pueda alcanzar directamente.
   
5. Haga clic en la ficha avanzadas y, a continuación, haga clic en el botón configuración.
   
6. En el cuadro de diálogo de configuración del servidor de puerta de enlace, haga clic en usar esta configuración del servidor de puerta de enlace de TS. A continuación, escriba el nombre del servidor (debe coincidir exactamente con el nombre en el certificado del servidor SSL) y seleccione un método de inicio de sesión. Haga clic en Aceptar para guardar la configuración.
   
7. Después de la personalización de cualquier otra opción de configuración, haga clic en la ficha General y haga clic en Guardar como para guardar la configuración a un archivo de formato RDP. Porque el archivo RDP incluye la configuración de TS Gateway, puede distribuirla a cualquier equipo que tenga instalado el servicio de cliente de escritorio remoto versión 6.0 o posterior.

Para conectarse al servidor, instruya al cliente que abra el archivo RDP y haga clic en conectar. Si se le solicita, proporcione las credenciales para los dos, tanto como para la puerta de enlace de TS y para el servidor de escritorio remoto. En pocos segundos, tendrá completo control sobre el servidor de escritorio remoto.

Nota: El cliente Remote Desktop versión 6.1, incluido con Windows Server 2008 y actualmente en la fase de prueba beta para otros sistemas operativos, puede configurarse para enviar las mismas credenciales a la puerta de enlace de TS y el servidor de escritorio remoto. Así será necesario entrar la contraseña del usuario una sola vez.

Así que si sus empleados tienen equipos en casa y conexiones de Internet de banda ancha, usted puede permitirles el uso del escritorio remoto para que ellos puedan controlar sus equipos de escritorio en el trabajo. Prácticamente al instante, sus usuarios tendrán acceso a sus archivos, aplicaciones, impresoras y otros recursos de red pertenecientes a la red interna como si estuviesen sentados en sus escritorios. De esta manera se evitara inconvenientes con firewalls o VPN… todo lo que los usuarios necesitan hacer es doble clic en un archivo de RDP que usted proporciona y listo!

¿Necesita más ayuda?

• Para obtener más información acerca de servicios de Terminal Server en Windows Server 2008, visite Terminal Services
• Microsoft también le ofrece un laboratorio virtual gratis que le permite trabajar con la puerta de enlace de TS sin configurar su propio entorno de laboratorio; este está disponible en TechNet Virtual Lab: Microsoft Windows Server 2008 Beta 2 Terminal Services Gateway and Remote Programs
• Para soporte técnico comunitario con los servicios de Terminal Server, visite Discussions in Windows Terminal Services

por Sebastian del Rio y Juan Carlos Albert

Problema

Al hacer una consulta DNS utilizando la herramienta nslookup a un host interno podemos recibir respuestas no deseadas, como por ejemplo la siguiente.

Escenario : Estamos en un “subdominio” del dominio “dominio.com.co”, desde ahora nuestro dominio sera “subdominio.dominio.com.co”

C:\Documents and Settings\usuario>nslookup
Default Server:  host.subdominio.dominio.com.co
Address:  192.168.0.1

>host.subdominio.dominio.com.co

Non-authoritative answer:
Name:    host.subdominio.dominio.com.co.com.co
Address:  74.53.50.168 < Tenemos una respuesta a un recurso interno , resuelta hacia una IP publica.

Lo bueno es que esto es un comportamiento default :) . Lo malo es que no debería pasar vamos a tratar de explicar esto un poco mejor.

Que es lo que sucede ?

Nslookup utiliza el mecanismo de devolution para realizar búsquedas en el DNS.

Devolution es el mecanismo mediante el cual los clientes DNS de Windows construyen los sufijos cuando la maquina no tiene configurado un listado explicito de sufijos de búsqueda.

Específicamente, la resolución envía una consulta DNS para el nombre que se ha solicitado resolver. Si la consulta fue realizada para un nombre de host de etiqueta única, se concatena al nombre del host el sufijo principal DNS del equipo local. Si esa consulta no se resuelve correctamente, la consulta se reintenta repetidamente quitando la parte izquierda del nombre de sufijo DNS principal restante hasta que la consulta o bien se ha resuelto o se alcanza el límite de descomposiciones recursivas. Este límite es dos por default, lo que quiere decir que si nuestro dominio es subdominio.dominio.com, el mecanismo de devolution hará que las búsquedas se hagan con los sufijos:

subdominio.dominio.com
dominio.com

Este límite es perfectamente válido para dominios de segundo nivel, tal como microsoft.com porque al llegar al sufijo de segundo nivel (microsoft.com) todavía estaremos bajo la autoridad del DNS interno.

En el caso de dominios de tercer nivel, sin embargo, el límite en dos resulta inapropiado porque devolution nos dará un sufijo de dos niveles que no está bajo la autoridad de nuestro DNS interno. Si este sufijo corresponde a un ccSLD (country code second-level domain), la consulta será enviada a la Internet para su resolución.

En nuestro ejemplo la lista de búsqueda provista por el mecanismo de devolution estará compuesta de la siguiente manera:

subdominio.dominio.com.co
dominio.com.co
com.co

La última consulta será eventualmente enviada a la Internet porque el sufijo que se anexa, com.co, no corresponde con ninguna zona en nuestro DNS.

Veamos lo que sucede al hacer la consulta a host.subdominio.dominio.com.co. Nslookup intenta primero resolver mediante su lista de búsqueda, agregando los sufijos uno por uno. Para chequear la lista de búsqueda que será utilizada, podemos hacerlo ingresando a nslookup y ejecutando “set all”

De manera que las consultas quedarían de la siguiente manera

C:\Documents and Settings\usuario>nslookup
Default Server:  host.subdominio.dominio.com.co
Address:  192.168.0.1

> set debug
> host.subdominio.dominio.com.co

Server:  host.subdominio.dominio.com.co
Address:  192.168.0.1

------------

Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        host.subdominio.dominio.com.co.subdominio.dominio.com.co, type = A, class = IN

    AUTHORITY RECORDS:    
->  subdominio.dominio.com.co
        ttl = 3600 (1 hour)
        primary name server = host.subdominio.dominio.com.co
        responsible mail addr = admin
        serial  = 611275
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

host.subdominio.dominio.com.co.subdominio.dominio.com.co  -> No hay respuesta ya que el registro host.subdominio.dominio.com.co no existe en la zona subdominio.dominio.com.co. (Ver Questions = 1 answers = 0)

------------

------------

Got answer:
    HEADER:
opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        host.subdominio.dominio.com.co.dominio.com.co, type = A, class = IN

    AUTHORITY RECORDS:
    ->  dominio.com.co
        ttl = 3600 (1 hour)
        primary name server = host.subdominio.dominio.com.co
        serial  = 417
        refresh = 3600 (1 hour)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

host.subdominio.dominio.com.co.dominio.com.co   -> No hay respuesta ya que el registro host.subdominio.dominio.com.co no existe en la zona dominio.com.co (Ver Questions = 1 answers = 0)

------------

------------

Got answer:

    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        host.subdominio.dominio.com.co.com.co, type = A, class = IN

    ANSWERS:
    -> host.subdominio.dominio.com.co.com.co
        internet address = 74.53.50.168
        ttl = 86400 (1 day)

host.subdominio.dominio.com.co.com.co   -> En el tercer caso estamos consultando el registro host.subdominio.dominio.com.co en la zona .com.co y será posible obtener una respuesta no autoritativa de nuestro servidor.

------------

Non-authoritative answer:

Name:    host.subdominio.dominio.com.co.com.co
Address:  74.53.50.168 - > Y aquí tenemos la respuesta.

Al esa zona no existir localmente (Ya que nuestra zona es subdominio.dominio.com.co ) y de acuerdo a la configuración de nuestro DNS utilizaremos los Fowarders o bien Root Hints para que otro servidor DNS resuelva nuestra consulta, lo que pasa aquí es que la zona .com.co se encuentra registrada en internet por lo cual la respuesta de este ultimo query existe. En este punto NSLOOKUP ya obtuvo su respuesta y no sigue haciendo queries.

El problema parece manifestarse con más frecuencia porque muchos DNS que resuelven zonas de segundo nivel (como com.co) están utilizando mecanismos de “catch all” para recoger todas las consultas no resueltas y retornar direcciones validas con fines comerciales o informativos. Intenten, por ejemplo, acceder a http://74.53.50.168

Cabe aclarar que luego del ejecutar el query solicitado y nslookup no haya obtenido ninguna respuesta utilizando su search list, se haría la consulta solicitada. Como en nuestro caso utilizando la search list ya tenemos una respuesta nunca se llega a solicitar el recurso que nosotros estamos intentando ubicar.

También es interesante considerar el hecho que devolution solo interviene si la consulta no es una completamente calificada (fully qualified). Afortunadamente podemos hacer la consulta FQDN utilizando un “.” al final del nombre de nuestro dominio.

Solución

Sabiendo que el problema se causa al consultar la Search List default de Nslookup las opciones que tendríamos serian las siguientes.

1 – Utilizar el sufijo “.” ( Sin comillas ) asignado mediante GPO , o bien localmente en la placa de red. De esta manera la search list quedaría compuesta por los sufijos que utilizemos en esta configuración.

NOTA : Para asignar la lista de sufijos DNS mediante GPO puede utilizar la siguiente nota 

2 – Desactivar la opción de Name Devolution (Mediante esta opción Nslookup no armaria su propia lista de Search list), este cambio debería habilitarse localmente en cada una de las maquinas mediante la modificación del registro según indica la siguiente nota http://technet.microsoft.com/en-us/library/cc959477.aspx.

3 – Utilizar el paramentro nosearch en la consulta mediante nslookup.

Esperamos haber aclarado algunas dudas que últimamente se dieron de acuerdo a este tema.

Happy Networking y hasta pronto!

Por: Renie Aloisi Mansur

Objetivo

O objetivo deste artigo não é prover uma abordagem profunda sobre DNSSec e suas variantes, mas sim, uma visão prática e direta de sua configuração. Para mais detalhes, recomendo a leitura do DNSec guide em que toda a instalação foi baseada e, em breve, será atualizado!

Introdução

O DNS é uma infraestrutura essencial praticamente, para qualquer ambiente. Usuários ou aplicações, por exemplo, raramente localizam outros computadores diretamente por endereço IP. Contudo, do ponto de vista de segurança, este serviço está sujeito a vários tipos de ataques, como por exemplo, spoofing, man-in-the-middle etc. Você se lembra do recente bug descoberto por Dan Kaminsky, que afetava diversas plataformas que utilizavam o DNS?

Vulnerabilidades deste tipo podem comprometer uma organização de n maneiras. Por esta razão, o desenvolvimento de uma maneira segura de utilizar o DNS ficou crítico. DNSSec (Domain Name System Security Extensions) são extensões que adicionam segurança ao DNS e são baseadas nas RFCs 4033, 4034 e 4035. Basicamente, o DNSSec provê a identificação da origem e integridade da informação recebida/enviada. Essa garantia é feita por quatro novos tipos de registros, que são eles: DNSKEY, RRSIG, NSEC e DS.

Recentemente, tive a oportunidade de participar da implantação de DNSSec numa grande instituição financeira utilizando a versão mais atual de nosso sistema operacional, o Windows Server 2008 R2 e gostaria de compartilhar, de maneira direta, como realizar esta ação com sucesso!

Instalando o DNS

O primeiro passo é instalar a função de DNS no Windows Server. Clicamos em Add role, conforme a imagem abaixo e selecionamos DNS Server.

A partir deste momento, devemos criar a zona DNS desejada como faríamos normalmente, sem nenhuma novidade aqui. Caso haja uma zona criada, precisamos exportá-la para um arquivo (usaremos este arquivo futuramente para assiná-lo)

Importante: Ao utilizar o DNSSec, todas as atualizações nesta zona serão feitas de maneira manual, pois o DNSSec não trabalha com Dynamic Updates. Por isso, o planejamento de qual zona será assinada é essencial.

Passos para o DNSSec

Agora, precisamos criar o par de chaves para assinar a zona que criamos anteriormente. Estas chaves são a KSK e a ZSK. Utilizamos os comandos abaixo para criá-las:

KSK:

DnsCmd /OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length <length> /Zone <zone name> /SSCert /FriendlyName KSK-<zone name>

ZSK:

DnsCmd /OfflineSign /GenKey /Alg rsasha1 /Length <length> /Zone <zone name> /SSCert /FriendlyName ZSK-<zone name>

Para melhor entendimento, segue um exemplo de nosso ambiente:

Importante: O tamanho da chave varia de 512 a 4096 (incremental de 64). O consumo de memória pode aumentar até cinco vezes ao utilizar o DNSSec. Por esse motivo, tenha um baseline do consumo atual para definir o tamanho das chaves que serão utilizadas.

Após criarmos as chaves, recomendamos fazer um backup e copiá-las para um local seguro, para tal, acesse a console de certificados via mmc, selecione os certificados do seu computador, clique com o botão direito nos certificados em questão e siga o assistente para exportá-los:

Com as chaves criadas e o backup efetuado, assinaremos a zona desejada. Para atingir este objetivo, utilizaremos o seguinte comando:

DnsCmd /OfflineSign /SignZone /input <input zone file> /output <output zone file> /zone <zone name> /signkey /cert /friendlyname ksk-<zone name> /signkey /cert /friendlyname zsk-<zone name>

Para facilitar a visualização, em nosso ambiente, fizemos assim:

A partir deste momento, temos uma zona assinada, entretanto, ainda não está em uso. Nosso próximo passo é remover a zona não assinada e carregar a mesma zona, contudo, assinada. Uma maneira simples de fazer esta ação é utilizar a interface gráfica do DNS, como mostramos abaixo:

Pronto! A zona está carregada e com as extensões DNSSec adicionadas:

Importante: Quando o DNS faz validação de uma zona que ele não é autoritativo, precisamos configurar o Trust Anchor. Basicamente, um Trust Anchor é outro servidor DNS configurado com DNSSec em que temos confiança na troca de informações. Ele tem sua informação gravada no arquivo keyset-<zone name>, dentro de %windir%\system32\dns. Seu formato consiste em:

<zone name> <TTL> IN DNSKEY <Flags> 3 5 <Base64Data>; key tag = <key tag>

Para adicionar um Trust Anchor, utilizamos o seguinte comando:

DnsCmd /TrustAnchorAdd <zone name> DNSKEY <Flags> 3 5 <Base64Data>

Abaixo, exemplo prático desta ação seguido da visualização pela interface gráfica do DNS:

Feito! Agora, seu DNS está muito mais seguro!

Informação

Alguns sistemas operacionais, por exemplo, da Microsoft, Windows Server 2003 e Windows Server 2008 tinham certa suportabilidade ao DNSSec conforme a RFC 2535. Há pouco tempo, esta mesma RFC ficou obsoleta sendo substituída pelas RFCs 4033, 4034 e 4035. Tanto o Windows Server 2008 R2 quanto o Windows 7, são baseados nas RFCs mais atuais para utilização do DNSSec.

E aí, vai atualizar?