Buscar

Mostrando entradas con la etiqueta Consulta técnica. Mostrar todas las entradas
Mostrando entradas con la etiqueta Consulta técnica. Mostrar todas las entradas

Active Directory: Usuario no puede cambiar password

Una consulta técnica muy interesante que me han realizado es la siguiente:

Escenario:

En un entorno de Active Directory:

- Un usuario no puede cambiar el password, en cambio el administrador si puede hacerlo.

- La opción de la ficha del usuario: "El usuario no puede cambiar la contraseña" (*) está desmarcada.

(*) Usuarios y equipos de Active Directory (dsa.msc), propiedades sobre un usuario, pestaña "Cuenta", apartado "Opciones de cuenta", opción: "El usuario no puede cambiar la contraseña". 

Veeam Backup: RAID repositorio

Una de las preguntas que se hacen los administradores de sistemas que utilizan Veeam Backup como herramienta de respaldo es qué tipo de RAID (Redundant Array of Independent Disks) utilizar en el almacenamiento que se utiliza como repositorio para el backup.

Antes de continuar: Hemos de tener en cuenta que puede que cambiemos el nivel de RAID de nuestro repositorio y no encontremos mejora alguna, esto sería debido a que el cuello de botella (bottleneck) no reside en el repositorio, por ejemplo, el cuello de botella puede ser la red o la infraestructura virtual a respaldar entre otros.

Vamos a la pregunta en cuestión: ¿Qué tipo de RAID utilizar en el storage que se utiliza como repositorio?

La respuesta es bastante sencilla, se cumplen las reglas generales acerca del rendimiento, redundancia y espacio de los niveles de RAID.

Consulta técnica: De Exchange 2003 a Exchange 2013

Estimado Xavier,

Soy un seguidor tuyo desde que Josep te recomendó en su blog; de hecho tengo compradas todas tus publicaciones; quiero abusar de tu confianza por una cuestión en la que me he embarcado y de la que pretendo sea un caso de éxito.

Estoy preparando la migración de un Exchange 2003 Server a un Exchange 2013, en un dominio ya existente. Estoy intentando documentarme lo más posible y no ha manera de realizarlo directamente sin sw de terceros.

EL caso es que ese software de terceros precisa montar un nuevo bosque y realizar la migración para posteriormente pasarla al bosque original, estoy intentando todavía entender los detalles.

Me gustaría conocer tu parecer y consejos de como realizar esta migración de la forma más segura posible... todo está en producción por lo que la cosa se complica un poco más. Creo que tus comentarios nos pueden aportar mucho para llevar este tema a buen puerto.

Muchas gracias por anticipado.

Y te animo a que sigas trabajando en tu línea editorial, pues a mi concretamente, me has aportado una visión de las materias que has tratado de forma muy valiosa.

Un fuerte abrazo.

---

Hola,

Primero de todo agradecerte la confianza por comprar los libros y lo más importante para mi es que te hayan gustado y resultado útiles, esta es la mayor recompensa para continuar trabajando en el blog y en nuevas publicaciones.

Sobre la cuestión que comentas, primero de todo confirmarte la conclusión a la que has llegado: no es posible saltar de EX2003 a EX2013 directamente sin SW de terceros. 

Siempre se permite pasar como máximo de dos en dos, es decir de EX2003 a EX2010 o de EX2007 a EX2013.

Las grandes ventajas respecto a EX2003 como: OWA compatible con los navegadores actuales, versión mejorada de Active Sync, bases de datos (EDB) sin límite de tamaño y hasta 4 en en la versión Standard, sistema operativo de 64 bits, etc, están también con EX2010.

A partir de aquí, mi recomendación seria pasar a EX2010 y dejarlo así.

En el 2016 está pensado que aparezca EX2016 y con EX2010 podrías pasar a EX2016 en el futuro.

Eso sí, si tuviera que hacer una instalación de Exchange nueva en un entono donde no hay Exchange, instalaría EX2013, ya que además de poder utilizar las nuevas funcionalidades que aporta la versión, obtendré un ciclo de vida del producto más largo, teniendo en cuenta que ya llevamos un año de parches desde la versión RTM.

No soy partidario de utilizar SW de terceros ya que las migraciones de EX acostumbran a dar problemas, problemas que tienen solución pero son molestos ya que los usuarios utilizan continuamente el servicio.

Los problemas que puedas encontrarte en una migración de Exchange utilizando el procedimiento propio de Microsoft, encontrarás las soluciones en el propio Technet, soporte de Microsoft o en foros del Technet.

Sobre cada cuando es conveniente migrar de versión un software como Exchange, depende de muchos factores.

Es importante mantener los productos dentro del ciclo de vida del fabricante además de evaluar las funcionalidades de cada nueva versión así como el coste que representa actualizar.

A día de hoy (01/12/2014):

Hay empresas como VMWare que ya han pasado a EX2013:

http://www.sysadmit.com/2014/09/vmware-ya-usa-exchange-2013.html

Mientras que otras como la propia Microsoft, continúan con la versión EX2010:

https://mail.microsoft.com/owa/
OWA sobre Exchange 2013, diciembre de 2014
Te comento este aspecto de cara a estudiar, valorar y argumentar cada cuando conviene actualizar o no un producto y si conviene o no realizar una actualización fuera del procedimiento del fabricante.

Tanto si pasas a EX2010 o bien por requisitos del cliente necesitas pasar a EX2013, te aconsejaría:

1) Montar un laboratorio completo a partir de los servidores de producción:

Utilizando un backup completo de AD y EX, rescatarlo en un entorno de pruebas separado de producción y sobre ese entorno realizar todo el procedimiento.

Ten en cuenta que en muchas ocasiones, las instalaciones que encontramos en un entorno de producción difieren de una instalación limpia que puedas realizar para realizar el laboratorio, desde versiones de binarios hasta configuraciones específicas.

2) Dimensionar correctamente el servidor:

El dimensionado del servidor de un EX2010 es muy distinto a un EX2003, pero es muy similar a un EX2013.

Tienes un capítulo en el libro EX2013ADM dedicado al tema que te aconsejo que analices con profundidad, te valdrá también para EX2010.

Un abrazo, y muchas gracias por seguirme!

Xavi.

Consulta técnica: Versión SMB entre Unix y NAS

Hola Xavier, antes de nada te felicito por tus libros, ya tengo toda la colección.

Estoy mirando de reducir el tiempo en que se hacen los backups. 

Debo hacer copias completas de un hardware físico Unix sobre un NAS (ahora se hacen en cinta).

Mi duda es: en el libro de WFS comentas que hay un incremento importante de rendimiento si el protocolo SMB negocia a 2.0 o más, mi entorno es un servidor Unix SCO físico y copias sobre un NAS con SMB. 

El servidor no es virtualizable ya que tiene una tarjeta especial de control de una máquina industrial. La conexión con la máquina no se hace por RS232. Entre el Unix y el NAS ¿Cómo puedo saber a qué versión de SMB negocian? Está claro que el comando de powershell Get-SmbSession del libro WFS no funciona sobre Unix.

Muchas gracias por anticipado.




Hola Andrés,

Primero de todo, transmitirte que me alegro mucho que te hayan gustado todos los libros.

Por otro lado, me encanta que puedas aprovechar conocimientos de libros de sistemas Windows sobre Unix.


Una pequeña referencia al libro de WFS sobre el tema que comentas, para aquellos que aún no lo habéis leído:


Consulta técnica: Versión SMB entre Unix y NAS

Consulta técnica: Versión SMB entre Unix y NAS
Consulta técnica: Versión SMB entre Unix y NAS


Efectivamente existe un incremento de rendimiento importante entre las versiones de protocolo SMB 1.0 y 2.0.

Como indicas en tu correo faltaría averiguar a qué versión están negociando y por qué.

Para averiguarlo bastaría con que conectes por SMB un equipo Windows 8 o Windows Server 2012 o superior y realices una conexión SMB hacia el Unix y mires a cuanto negocian, después repites la operación contra el NAS.

La idea es que tanto Windows Server 2012 como Windows 8 pueden trabajar con SMB 3.0 siempre y cuando los extremos que actúan de cliente SMB y servidor SMB también soporten SMB 3.0. Si no es así, se negocia a la versión de protocolo más baja.

Ejemplo:

Posible caso 1:

W2012 - Unix : 1.0 : En este caso Unix solo soporta SMB 1.0
W2012 - NAS : 2.0 : En este caso NAS solo soporta SMB 2.0

Si conectan Unix y NAS negociarán el valor más bajo: 1.0

Posible caso 2:

W2012 - Unix : 2.0 : En este caso Unix solo soporta SMB 2.0
W2012 - NAS : 2.0 : En este caso NAS solo soporta SMB 2.0

Si conectan Unix y NAS negociarán el valor más bajo: 2.0

Recuerda que efectivamente el rendimiento SMB 1.0 vs SMB 2.0 es superior, pero también recuerda otros factores a tener en cuenta como el uso de RAM, Ethernet, discos, etc tanto en origen (Unix) y destino (NAS).

¡Ya me contarás si te ha funcionado!

Un saludo,

Xavi.

Consulta técnica: Límites de Exchange, exportación a PST


Hola Xavier, fantástico tu libro de Exchange 2013.

Pero he buscado por todo el libro y no veo cómo puedo saber el espacio que se le ha dado a cada base de datos y el espacio que le queda libre.

Si voy a MiPc. Veo las carpetas de las Bases de Datos y de ahí puedo saber qué es lo que ocupa cada una de ellas, pero no puedo saber el espacio libre, el disponible que me queda en la Base de datos.

Tengo 4 Bases de Datos, ya que tengo la versión Standard de 500GB cada una, si tengo que ampliar una Base de Datos ¿Cuál es el comando? ¿se puede hacer en caliente o tengo que desmontarla primero?

¿Puedo Exportar un Buzón de Exchange a un PST con facilidad desde el Exchange?

¿Existe en Exchange alguna opción de Archivado de Correos tipo como la de GFI Mail Archiver?

Gracias de antemano.
Salu2

----

Hola Ramón,

Primero de todo agradecerte la confianza por haber comprado el libro de Exchange 2013 y decirte que me alegro mucho de que te haya gustado.

Todas las preguntas que planteas son preguntas frecuentes que tienen los administradores de Exchange y que alumnos, lectores me plantean en muchas ocasiones.

Por este motivo he preferido contestar a tus preguntas en este post del blog, de esta forma muchos administradores podrán utilizar la información.

Contesto tus preguntas a continuación:

1) Límites BD

En Exchange 2003 Standard con SP2 instalado y aplicando una clave en el registro de Windows podías pasar de los 16GB a los 75GB de límite de base de datos EDB, sin embargo solo podrías disponer de una sola base de datos además de las carpetas públicas.

Como dispones de la versión Standard y cuatro bases de datos, dispones de Exchange 2007 o 2010 o 2013.

A partir de Exchange 2007 aunque dispongas de la versión Standard, el límite de base de datos EDB es de 16TB, a día de hoy sería como decir que no hay límite.

Por otro lado puedes poner límites sobre la base de datos, pero estos límites corresponderán a la cuota de los buzones no al límite del EDB.

Por defecto los buzones heredarán el valor del límite fijado en la base de datos.

Puedes ver el tema en los siguientes puntos del libro:

8.1.8. LÍMITES A NIVEL DE BD
8.1.9. LÍMITES A NIVEL DE USUARIO

Este concepto sirve para todas las versiones de Exchange.

Recuerda: el tamaño del EDB no tiene límite a partir de Exchange 2007.

2) Exportar a PST

Puedes exportar buzones a PST desde el servidor de Exchange.

Con Exchange 2003 dispones de la utilidad EXMERGE, el problema de EXMERGE es que el formato del PST resultante es ANSI por lo tanto tiene un límite de 2GB.

Con Exchange 2007 dispones del cmd-let de PowerShell de Exchange: Export-Mailbox

Dispones de un ejemplo de funcionameinto de este cmd-let con Exchange 2007 en el apartado del libro:

12.1.2. EXPORTACIÓN/IMPORTACIÓN A PST

Export-Mailbox sobre Exchange 2007 tiene dos problemas:

1- Necesita las librerías de Outlook para funcionar.
2- Necesitas permisos sobre el buzón que quieras exportar.

Para solventar el primer problema y no instalar Outlook sobre el servidor, puedes utilizar un equipo añadido al dominio (no es necesario que sea Windows Server, puede ser Windows cliente (XP/7)) e instalarle las Exchange Management Tools y Outlook.

Para instalar las Exchange Management Tools basta con lanzar la instalación utilizando los ficheros de instalación de Exchange del DVD o ISO y seleccionar solo Management Tools.

Si no dispones del DVD o ISO de instalación, puedes descargar el último Service Pack, ya que no solo sirve para parchear si no que también puedes realizar una instalación nueva con el mismo.

Si el equipo es de 32 bits, puedes descargar las Management Tools de la web de Microsoft:


Es importante tener en cuenta:

- Necesitarás instalar las versiones de .NET y PowerShell necesarias para funcionar, como si se tratase de una instalación completa de Exchange.

- Parchea utilizando el último Service Pack y Update Rollup.

Para Exchange 2010 o 2013 no es necesario realizar todos los procedimientos anteriores:

Puedes exportar directamente desde la PowerShell del servidor de Exchange sin disponer de las librerías de Outlook y además no necesitas permisos en los buzones que desees exportar.

Tienes el proceso detallado en los siguientes puntos del libro (válido para Exchange 2010 y Exchange 2013):

12.2.1. ROL DE IMPORTACIÓN/EXPORTACIÓN PST – BUZÓN [PS]
12.2.5. EXPORTACIÓN MASIVA DE BUZONES A PSTS [PS]
12.2.4. EXPORTACIÓN CON FILTRO POR FECHA [PS]
12.2.6. ELIMINACIÓN DE CONTENIDO DE LOS BUZONES [PS]

Con Exchange 2013 puedes también exportar desde GUI:

12.2.7. IMPORTACIÓN / EXPORTACIÓN: BUZONES A PST O VICEVERSA [ECP]

3) Opción de archivado del servidor

A partir de Exchange 2010 SP1 dispones de la opción de archivado.

La idea consiste en configurar en el servidor de Exchange una nueva base de datos y cuando el usuario desde el Outlook marque un correo como archivado, este será movido a la base de datos de archivado.

El problema de esta funcionalidad es que dispondrás de un EDB dedicado al archivado ocupando espacio en el servidor de Exchange.

4) Conclusiones

Si el rendimiento del servidor de Exchange no es bueno debido al tamaño de los EDB, hay muchas formas de solucionar el problema, entre ellas:

- Instalar otro servidor de Exchange y repartir los buzones.
- Pasar de la versión Standard a Enterprise y situar más EDB.
- Opciones de archivado.
- Aumentar el hardware: más RAM, más HDD, etc..

Pero la solución más barata y que te ofrecerá una mayor tranquilidad (ya que el tiempo de backup y recuperación de desastres será menor) es adelgazar el tamaño de los EDB.

Para ello puedes pactar el número de años que se quiere disponer de correo online, por ejemplo: 5 años.

Una vez pactado el tiempo podrás exportar masivamente a PST los elementos que sean más antiguos de 5 años y luego borrar el contenido exportado de los EDB.

Estos PST quedarían desconectados de los Outlooks para evitar que sean modificados por los usuarios y a la vez evitar la necesidad de realizar copias de seguridad de los mismos.

Solo serian conectados bajo demanda.

Con esto adelgazarías el tamaño de los EDB para tener un Exchange más ágil y rápido.

Recuerda una vez limpiado (export y delete de correos) que el tamaño del EDB no se reducirá.

O bien creas EDBs nuevos y vas moviendo los buzones o bien realizas una defragmentación offline del EDB con eseutil.

Recuerda que defragmentación offline del EDB significa que el EDB debe ser desmontado durante el proceso.

El proceso puede tardar mucho dependiendo del hardware del servidor.

Dispones de cómo realizar el proceso y todos los elementos a tener en cuenta en el punto del libro (válido para todas las versiones de Exchange):

8.1.7. DEFRAGMENTACIÓN OFFLINE

También has de tener en cuenta el retention time, activado por defecto en todas las versiones de Exchange.

Si está activado, cuando borras correos o buzones, no se borran de inmediato si no que quedan marcados para ser borrados al cabo de X tiempo.

Sería conveniente cambiar este valor antes de empezar a exportar y borrar.

Punto del libro: 8.1.5. RETENTION TIME

¡Espero haberte ayudado!

Saludos,

Xavi.