MCT Maitchovcow

COnfigurar Proxy desde GPO

2018-11-12T18:23:00.003+01:00

Hola a todos. Como creamos la configuración de proxy para nuestras máquinas cliente con GPO

Lo primero que debemos saber es que debemos tener los permisos adecuados para hacer el siguiente cambio. Dentro del directorio Activo

En la consola de administración de políticas de grupo, abra cualquier política existente o cree una nueva, luego navegue a uno de los siguientes destinos:

Configuración de usuario> Preferencias> Configuración de Windows> Registro = Para aplicar la configuración a nivel de usuario, esta configuración seguirá al usuario en cualquier computadora en la que haya iniciado sesión

Configuración de la computadora> Preferencias> Configuración de Windows> Registro = Para aplicar la configuración en el nivel de la computadora, esta configuración se aplicará en la computadora para cualquier usuario que haya iniciado sesión en la computadora

En este ejemplo, estamos usando la primera opción que es aplicar la configuración en el nivel de usuario.

Habilitando la configuración de proxy

En este paso, crearemos el registro para habilitar la configuración de proxy. Rellene los campos de la siguiente manera:

Acción: Actualizar

Hive: HKEY_CURRENT_USER (si la configuración se aplicará a nivel de usuario) o HKEY_LOCAL_MACHINE (si la configuración se aplicará a nivel de computadora)

Ruta clave: Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings

Nombre de valor:WinHttpSettings

Tipo de valor: REG_DWORD

Datos de valor: 00000001

Base: hexadecimal.

Como podemos saber el valor del Hexadecimal?

Entramos en una maquina con el CMD

Y con el comando set proxy [proxy-server=] [bypass-list=]

Ejemplo:

netsh winhttp set proxy proxy.miempresa.local:8080 *local;microsoft.com;intranet.local;

Ahora buscaremos la Clave de registro en la siguiente ruta del regedit

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections

A continuación debemos exportar esta rama del registro.

Seleccionaremos una ubicación para el archivo

Indicando que solo exportaremos la rama seleccionada.

A continuación, editamos con un Notepad este fichero.

Ahora quitaremos del fichero los espacios y los separadores /

Quitado los separadores / ahora queda una sola línea con toda la cadena.

Ahora remplazaremos la , por null. O en blanco.

Remplazaremos todas las ,

Hora con la cadena limpia procedemos a copiar la cadena en nuestra GPO.

Ahora linkcamos la GPO a la OU

Recordar que debemos hacer un GPOUpdate /forcé para completar la implementación.

Espero que fuera de utilidad. Y si os ha gustado compartirla.

Paso a Paso 365-ADFS-Azure Capitulo 1

2016-04-03T17:26:00.000+02:00

Hola a todos. Muchas gracias por leer este blog de nuevo.

Quisiera destacar la importancia de estos pasos para el despliegue correcto de Office 365, Intune, Entre Otros Servicios Cloud.

¿Es necesario tener AD-DirSync? - No, sin embargo los usuarios de nuestra nube, no tendrán la misma contraseña ni se llevaran la misma nomenclatura, por ellos la administración de los usuarios On-Premise y Cloud se gestionan de manera independiente, Ademas de no poder utilizar el Single sign-on (SSO) y en consiguiente los usuarios serán obligados a realizar Login varias veces dependiendo de los servicios a activar. (Solo con DirSync no lograremos el SSO...), Nuestros usuarios Cloud tendrán el mismo SID, On-Premise.

Active Directory Fereration Services (ADFS), es el servicio Fundamental para lograr el SSO, y lo que nos permite es usar nuestro usuario y contraseña, o propiedades el usuario como grupos de pertenecía, ante servicios externos, algunos ejemplos de utilización, unificación de servicios empresariales de DropBox, Office 365, zscaler, Etc...

En los siguientes entradas ir desgranado paso a paso el despliegue necesario para desde 0, desplegar los servicios necesarios para una integración completa de Directorio Activo On-Premise y AzureAD, Junto con ADFS.

Así será la infraestructura, resultante.

En el caso practico que vamos a utilizar, solo utilizaremos PowerShell.

Vamos a empezar Definiendo la Red que para nosotros será la Red Privada donde estarán ubicadas las maquinas virtuales destinadas para el ADFS, que se sincronizara con la red interna atreves de ExpressRouter o VPN (Site-Site), Adicionalmente crearemos otra red donde expondremos nuestros ADFS-Proxy que será la DMZ, el cual serán publicados a internet para los servicios...

En este capitulo crearemos las redes necesarias para desplegar los servicios.

El primer paso es crea el grupo de seguridad de Red:

Lo primero será desplegar el Grupo de seguridad de red que se utilizara por defecto, utilizaremos el siguiente comando de line.

New-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" -Location "North Europe" -Label "Grupo de Seguridad DMZ SubRed"

una vez creado el grupo de seguridad podremos visualizar las reglas predeteminadas, y asi asociarlas.

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" -Detailed

El siguiente paso es añadir cualquier reglas de entrada para el grupo de seguridad de red que requerimos. Es decir el tráfico de entrada a la subred que el grupo de seguridad de red será asignado a más tarde. En este ejemplo, el tráfico de entrada a la subred que se utiliza como la red privada y los servidores proxy. Estas reglas no se limitan a permitir , sino también reglas de denegación.

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name "Permitir entrantes RDP de todas las redes internas" -Type Inbound -Priority 110 -Action Allow -SourceAddressPrefix 'RED_VIRTUAL' -SourcePortRange '*' -DestinationAddressPrefix 'RED_VIRTUAL' -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name " Permitir HTTPS entrante desde Internet " -Type Inbound -Priority 120 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix "Red_Privada" -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name " Permitir entrantes RDP desde Internet " -Type Inbound -Priority 130 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix "RED_PRIVADA" -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name " Denegar el tráfico entrante a la subred de confianza " -Type Inbound -Priority 200 -Action Deny -SourceAddressPrefix 'RED_VIRTUAL' -SourcePortRange '*' -DestinationAddressPrefix 'RED_VIRTUAL' -DestinationPortRange '*' -Protocol '*'

Una vez que todas las reglas de entrada se han creado su momento de añadir reglas de salida . Una vez más se trata de tráfico saliente de la subred que se utiliza como la Privada en este ejemplo.

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name " Permitir salientes HTTPS de subred Privada" -Type Outbound -Priority 110 -Action Allow -SourceAddressPrefix 'RED_VIRTUAL' -SourcePortRange '*' -DestinationAddressPrefix 'RED_VIRTUAL' -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityRule -Name " Denegar el tráfico de salida de subred Privada" -Type Outbound -Priority 200 -Action Deny -SourceAddressPrefix 'RED_VIRTUAL' -SourcePortRange '*' -DestinationAddressPrefix 'RED_VIRTUAL' -DestinationPortRange '*' -Protocol '*'

Una vez más en esta etapa podemos usar el cmdlet " Get- AzureNetworkSecurityGroup ' con el interruptor -Detailed como anteriormente para obtener una salida de pantalla de las reglas ya configuradas en el Grupo de Seguridad de red.

El último paso para la configuración es asignar el Grupo de Seguridad de red a nuestra subred privada . Esta subred es donde se aplicarán las reglas de entrada y de salida una vez que el grupo de seguridad de red ha unido a la subred.

Get-AzureNetworkSecurityGroup -Name "DMZ-HTTPS" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName "RED_VIRTUAL_X" -SubnetName "Subnet_Privada"

Recordar que estos son ejemplo y que deben adaptarse a sus redes.

Si os a gustado no olviden compartirlo.

ACTUALIZACIÓN DE SCCM UP 1602

2016-03-30T18:39:00.000+02:00

Entre los avances técnicos nos permite permiten probar nuevas características en el entorno de prueba y nos proporciona valiosa información acerca de su experiencia. Hoy en día, estamos encantados de lanzar la actualización de 1602, nuestra última técnica previa. Las nuevas características que están disponibles en esta actualización se incluyen:

Ajustes de configuraciónpara los equipos Windows 10
Creación automática de aplicaciones móviles de Microsoft Office para iOS y Android están pre-creadas para los clientes que utilizan la integración con Microsoft ConfigMgr Intune con ls sincronización Políticas.
El nuevo botón Política de sincronización le permite ejecutar el ciclo de usuario y Política de directiva de equipo de recuperación y evaluación de recuperación y evaluación del ciclo con un clic de un botón.
Pestaña de opciones para el Centro de software de bajo mantenimiento Equipo Actualización in situ del sistema operativo de ConfigMgr Site Server.
Apoyo a la actualización en el lugar de ConfigMgr Sitio servidor de sistema operativo de Windows Server 2008 R2 a Windows Server 2012 R2.
iOS activación de la gestión de cerradura – Capacidades incluyendo propicio, las consultas a la situación, recuperar los códigos de derivación, y la realización de un by-pass de activación de bloqueo en los dispositivos iOS propiedad de la empresa.

Comprobacion de versiones.

Dentro de Administracion –> Cloud Service -> Updates and Servicing.

Dentro de las pocibilidades que tenemos son las siguientes.

y seleccionamos la instalación.

Adicionalmente les agrego un video explicativo muy corto.

Espero que les guste y compartirlo

Como generar informes personalizados con PowerBI

2015-07-23T22:41:00.002+02:00

Hola a todos hoy les traigo como siempre una receta para prepara, informasen y paneles personalizados con un gran producto como puede ser PowerBI.

Empecemos.

Necesitaremos los siguientes ingredientes:
Una hoja Excel.
Suscripción a PowerBI.
Cuenta de Google Analytics (Para este Ejemplo)
el cliente de Power BI para los Clientes por Ejemplo para Ipad.
Internet Explorer.
Conexión a internet (puede que algunos firewall puedan caparte la conexión)

iniciaremos sección en nuestro PowerBI.

https://powerbi.microsoft.com/

Una vez dentro del portal de PowerBI

Seleccionamos Get-Data

Seleccionaremos Services esto sera para configurar por ejemplo nuestra cuenta de Google Analytics.

Seleccionaremos Connect.

Ahora nos preguntara los siguientes datos.

Cuenta----
Propiedad----
Ver-----

Estos datos de donde los sacamos????

Me encanta que me hagas esa pregunta.

nos conectamos a la Web de Google Analytics y en el panel que tengamos configurado apareceran estos datos.

Algo como así

A continuación nos pedira que accedamos a nuestra cuenta de google.

Ahora nos pedira acceso a la aplicación.

Después de un poco de paciencia estar reportando vuestro Power BI.

Ahora vamos a hacerlos desde un Excel. Esto nos servirá tanto en local como para PowerBi hacer nuestros propios Report he Informes, de nuestro Office 365, al que me piden muchos clientes.

Abrimos un libro nuevo.

En el Tab de Data escogeremos por Ejemplo.

Seleccionaremos FromOdata (OJO esto no solo funcionaria con Office 365, También podría usarse para Exchange On Premiss y Lync o S4B).

Ponemos nuestra URL Local o Remota, en mi caso para Office 365 utilizo la siguiente URL.

https://reports.office365.com/ecp/reportingwebservice/reporting.svc/

Nuestro Usuario y Contraseña. de Office 365.

Seleccionaremos las tablas que quisiéramos traer, (Solo traer una por Hoja)
Repetiremos esta operación por cada tabla que quitaremos traernos al Libro de Excel.

Guradaremos la conexion si a posterior quereis que se actualice automaticamente, o exportarlo a Power BI guardar la contraseña.

Que queremos hacer con estos datos.

Yo selecciona una tabla.

Y aqui tenemos los datos para tratarlos como nos convenga.

Imaginaros que es un Cubo OLAP y así os sera más sencillo.

A continuación volvemos a nuestra pagina de PowerBI.

Seleccionaremos igual Get-Data

y Seleccionaremos Archivos.

Seleccionamos donde tenemos nuestros archivos. En mi caso los tengo en local.

Nos creara un conjunto de datos.

Seleccionando Informenes Nuevo en le símbolo de +

Seleccionamos el Recurso, y como queremos exponerlo. en mi caso he seleccionado una tabla.

Otro ejemplo seria que escogeremos un gráfico.

Ahora tendremos nuestros informanes disponibles en powerBI.

y así quedaria el panel en el Ipad.

Y con esto hemos terminado el día de hoy espero que lo habéis disfrutado.

Exchange 2016 ya está aquí

2015-07-22T20:03:00.001+02:00

Hola les traigo el link con Exchange 2016 para que se los descarguéis. Disfrutarlo

Hoy he actualizado el Link debido a los comentarios recibidos.

https://www.microsoft.com/en-us/download/details.aspx?id=49161

En que me certifico UM

2015-07-21T15:19:00.003+02:00

Aqui os dejo el resultado de un estudio de mercado basado en puestos de trabajo de varias paginas internacionales especializadas en empleo.

Aun estamos de Ultimo en la escala de demanda pero poco a poco subiremos. MCSE!!!!!!!

Aun que nos situamos casi por encima de Jabber de cisco, casi somos los líderes del mercado.

Skype For Business con PBX virtual...

2015-07-21T15:11:00.001+02:00

Hola a todos ya es oficial que PBX Cloud para Skype for Business esta en fase beta, con la colaboración de AT&T, BT, Colt, Equinix, Level 3 Communications, Orange Business Services, TATA Communications, Telstra, Verizon and Vodafone.

Los rumores apuntan a que a principios del año que viene tendremos el servicio en varios países de europa, incluidos desde el principio España.

EVO:RAIL VMWARE

2015-07-21T15:04:00.001+02:00

Lo sierto es que esto no es nada novedoso ya que conozco y estoy certificado en VCE V-Blok, antigua alianza Cisco-VMWARE-EMC la cual tiene una soluciones muchas mas solidas. pero después de probar esta solución les puedo decir que no tiene mucho que envidiar a VCE.

Aqui os dejo toda la información oficial. AQUI

ya tienes la opcion de activas Cortana desde la consola de Administracion de Office 365.

2015-07-21T14:53:00.001+02:00

Ahora puedes activar cortana en office 365 el cual se integrara con el correo electrónico, y Skype for Business

como recuperar el Directorio Virtual de IIS de PowerShell

2012-07-05T08:05:00.001+02:00

Hola existe varios motivos por el cual no podemos ver obligados a restaurar el directorio virtual de PowerShell, Para los que no conoces este directorio es al cual se conecta tanto la consola de Exchange mas conocida por EMC, o el PowerShell for Exchange, puede que nos tengamos que ver oblicagos a restaurar dicho directorios, para ello debemos seguir los siguientes pasos:

Abrir una consola de PowerShell en modo Administrador (En el servidor a restaurar).
Importamos los modulos de Exchange con el siguiente comando. “Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010”
Podremos listar los directorios de PowerShell que esta disponibles con el comando “Get-PowerShellVirtualDirectory |fl”.
Posteriormente debemos eliminar el directorio, para ello debemos ejecutar el siguiente comando.”Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
Remove-PowerShellVirtualDirectory -identity "powershell-vdir "”.(esto eliminara todos del anterior listado en caso de querer eliminar solo el del servidor, debemos ejecutar Remove-PowerShellVirtualDirectory -identity "powershell-vdir ")
Reiniciaremos el IIS “IISRESTART”
Crearemos el Directorio Virtual “New-PowerShellVirtualDirectory
Name: PowerShell”
Reiniciaremos el IIS “IISRESTART”
ahora desabilitaremos el que requiera certificado para su conexion “Set-PowerShellVirtualDirectory -identity "powershell-vdir" -RequireSSL:$false”

como convertir tu windows 7 en un punto de acceso

2012-07-05T07:42:00.001+02:00

Hola muchas veces no disponemos de wifi, y necesitamos que nuestros dispositivos se conecten a una red, y no disponemos de mas cables, o nuestros smartphone no dispone de este tipo de conexión, para ello podemos hacer que nuestro portátil o pc de casa actué de Punto de Acceso. En el siguiente apartado les dejo como configurar el windows 7.

Lo primero que debemos hacer es abrir un CMD en Modo Administrador.

netsh.exe wlan set hostednetwork mode=allow ssid=HotSpot key=ab123456789 keyUsage=persistent

Donde dice ssid es el nombre de la Wifi o su identificador, KEY colocaremos la clave de WEP que deseamos para nuestra WiFi en el caso de dejarla en blanco, la WiFi no sera segura y se configurara como una red Abierta.

A continuacion en el mismo CMD escribiremos “netsh.exe wlan start hostednetwork” con esto activaremos el servicio de punto de acceso.

NOTA: En el caso de algunos portátiles es necesario el habilitar la red WiFi antes de levantar dicho servicio. Esto dependerá de marca, modelo, y la configuración de ahorro de energía.

y a continuación abriremos el el centro de redes y centro compartido, Seleccionaremos configuración de adaptadores de red. Seleccionaremos el adaptador con internet, botón de la derecha, propiedades. Una vez abierto el cuadro de propiedades, seleccionaremos la pestaña compartir. Seleccionamos Habilitar esta red para otros usuarios y permitir que se conecten a este equipo para conectarse a internet. Seleccionaremos el adaptador correspondiente que será uno nuevo que se crea con la ejecución de las líneas de comando anteriores, y que será “Microsoft Virtual WiFi Miniport” y con esto ya tenemos configurado nuestro Windows 7 como un Punto de Acceso.

Migración detallada de Exchange 2003 a Exchange 2010

2012-07-03T16:35:00.001+02:00

Cualquier actualización de organización desde Exchange 2003 tendrá un período de coexistencia. En un escenario de coexistencia, cualquier combinación de las siguientes versiones de Microsoft Exchange se implementa en una única organización de Exchange: Exchange 2003, Exchange 2007 y Exchange 2010. Este tema se centra principalmente en la coexistencia de Exchange 2003 y Exchange 2010.

En un escenario de coexistencia, varias versiones de Exchange se pueden comunicar entre sí y compartir recursos de datos, información de destinatarios e información de configuración. Partes de la organización aún hacen uso de la funcionalidad Exchange 2003, y otras han completado la actualización a Exchange 2010.

Importante:

Solo se pueden instalar servidores de Exchange 2003 adicionales en la organización si había un servidor Exchange 2003 cuando se instaló el primer servidor de Exchange 2010.

Tenga en cuenta los siguientes problemas de coexistencia:

· Active Directory y dominios Al realizar la actualización de Exchange 2003 a Exchange 2010, primero debe conceder permisos de Exchange específicos en cada uno de los dominios en los que se ejecutó DomainPrep de Exchange 2003. Para hacerlo, ejecute el comando setup /PrepareLegacyExchangePermissions. La concesión de estos permisos forma parte de la preparación del servicio de directorio de Active Directory y sus dominios para la instalación de Exchange 2010. Para obtener instrucciones detalladas, consulte Preparar Active Directory y los dominios.

· Interfaces de administración En Exchange 2010, puede administrar servidores y buzones de Exchange 2010 mediante el uso de la Consola de administración de Exchange (EMC) o el Shell de administración DE Exchange. Además se puede usar la EMC para ver algunos atributos en servidores de Exchange 2003. Para obtener más información, consulte Interoperabilidad de la Consola de administración de Exchange.

· Características de rol de servidor Las características de rol de servidor de Exchange 2010 disponibles para los clientes en la organización de Exchange durante el período de coexistencia dependen de la versión del servidor de Exchange en el que está almacenado el buzón del usuario y la versión de la aplicación de cliente de correo electrónico que se usa para obtener acceso a Exchange.

· Grupos de enrutamiento En una organización grande, con muchos grupos de enrutamiento, se debe planear la topología de enrutamiento para mantener el flujo de correo durante el período de coexistencia. Al planificar un período de coexistencia entre Exchange 2003 y Exchange 2010, debe comprender de qué forma cada versión determina su topología de enrutamiento. Para obtener más información acerca del enrutamiento y la coexistencia, consulte Actualización desde el servicio de transporte de Exchange 2003.

· Modo nativo Exchange 2010 solamente se puede implementar en una organización de Exchange 2003 que funcione de modo nativo. Para obtener más información acerca de cómo cambiar su organización Exchange 2003 al modo nativo.

Diferencias de administración

Exchange 2003 usa grupos administrativos para organizar los objetos de Exchange para delegar el permiso para administrar estos objetos. Exchange 2010 no usa grupos administrativos como unidad de administración lógica para la delegación administrativa.

No obstante, para que sea posible la coexistencia entre Exchange 2003 y Exchange 2010, todos los servidores de Exchange 2010 se ponen en un único grupo administrativo cuando se instala Exchange 2010. Este grupo administrativo se reconoce en el Administrador del sistema de Exchange de versiones anteriores de Exchange como Grupo administrativo de Exchange (FYDIBOHF23SPDLT).

Precaución:

No mueva los servidores de Exchange 2010 fuera del grupo administrativo de Exchange (FYDIBOHF23SPDLT) y no cambie el nombre del grupo administrativo de Exchange (FYDIBOHF23SPDLT) mediante un editor de directorios de bajo nivel. Exchange 2010 debe usar este grupo administrativo para el almacenamiento de datos de configuración. No se admite el movimiento de los servidores de Exchange 2010 fuera del grupo administrativo de Exchange (FYDIBOHF23SPDLT) o el cambio de nombre del grupo administrativo de Exchange (FYDIBOHF23SPDLT).

Se debe usar el Administrador del sistema de Exchange y las utilidades para administrar los servidores de Exchange 2003. En Exchange 2010, debe administrar los servidores y los buzones de Exchange 2010 mediante la EMC o el Shell. Sin embargo, puede usar la EMC para ver algunos atributos en los servidores de Exchange 2003. Para obtener más información acerca de la interoperabilidad de la EMC.

Coexistencia de modo mixto de Exchange 2007 y Exchange 2003

Cuando esté listo para actualizar un entorno de modo mixto, actualice cada uno de los sitios de Active Directory por separado. Si cuenta con sitios de Active Directory que solo tienen disponible Exchange 2007 o Exchange 2003, siga las instrucciones siguientes para actualizar la versión pertinente del sitio de Active Directory. Por ejemplo, si dispone de Exchange 2007 en el sitio A de Active Directory, siga las instrucciones de actualización para Exchange 2007. Si, en cambio, tiene instalado Exchange 2003 en el sitio B de Active Directory, siga las instrucciones de actualización para Exchange 2003. Para obtener más información sobre cómo actualizar sus versiones de Exchange 2003 y Exchange 2007.

Si cuenta con sitios de Active Directory que tienen instalado Exchange 2003y Exchange 2007, siga las instrucciones de actualización de Exchange 2003 y Exchange 2007, y complete los pasos de actualización necesarios para ambos sistemas. Para obtener más información sobre cómo actualizar su sistema a Exchange 2010 en este escenario, consulte los siguientes temas:

Descripción de la actualización a Exchange 2010

Exchange Server 2010 se puede implementar en un bosque de Active Directory que tenga un sistema de mensajería existente. Se da una situación de coexistencia si se cumplen las siguientes condiciones:

· Exchange Server 2010 se implementa en una organización existente de Exchange.

· Existe más de una versión de Microsoft Exchange que proporciona servicios de mensajería a la organización.

No se puede actualizar una organización de Exchange 2000 existente a Exchange 2010 directamente. Primero, debe actualizar la organización de Exchange 2000 a una organización de Exchange 2003 o Exchange 2007 y, a continuación, puede actualizar la organización de Exchange 2003 o Exchange 2007 a Exchange 2010. Le recomendamos que actualice su organización de Exchange 2000 a Exchange 2003 y, luego, actualice de Exchange 2003 a Exchange 2010. Para obtener más información sobre la actualización de Exchange 2000, consulte Diseño de una actualización de Exchange 2000 y Actualizar a Exchange 2007.

Si una organización realiza el tránsito gradual de su sistema de mensajería de Exchange Server 2003 o Exchange Server 2007 a Exchange 2010, probablemente deba mantener más de una versión de Exchange durante ese tiempo.

En la siguiente tabla, se enumeran los casos en los que se admite la coexistencia de Exchange 2010 y versiones anteriores de Exchange.

Coexistencia de Exchange 2010 y versiones anteriores de Exchange Server

Versión de Exchange	Coexistencia de organización de Exchange
Exchange 2000 Server	No se admite
Exchange Server 2003	Se admite
Exchange 2007	Se admite
Organización mixta de Exchange 2007 y Exchange Server 2003	Se admite

Proceso de actualización de Exchange 2003 a Exchange 2010

Ésta es una descripción general de alto nivel de los pasos de actualización que se siguen para actualizar de Exchange 2003 a Exchange 2010.

En primer lugar, actualice todos los sitios de Internet Active Directory mediante los siguientes procedimientos:

1. Actualización de los servidores de Exchange 2003 existentes de Exchange 2003 Service Pack 2 (SP2).

2. Implemente los servidores de Exchange 2010 en este orden:

a. Acceso de cliente

b. Transporte de concentradores

c. Mensajería unificada

d. Buzón

3. Configure el servidor front-end de Exchange 2003 y el servidor de acceso de cliente de Exchange 2010.

4. Configure el servidor Transporte de concentradores de Exchange 2010 y los servidores Mensajería unificada.

5. Mueva los buzones de Exchange 2003 a Exchange 2010.

A continuación, actualice todos los sitios internos Active Directory de la misma manera.

La siguiente figura ilustra la descripción general del proceso de actualización de Exchange 2003 a Exchange 2010.

Orden de sitios de Active Directory para actualizar

Tal y como se muestra en la figura anterior, al actualizar una organización a Exchange 2010, se debe comenzar por los servidores que se encuentran en los sitios de Active Directory accesibles a través de Internet y, a continuación, actualizar los sitios de Active Directory internos. Este enfoque es necesario porque la conexión proxy del servidor de acceso de cliente al servidor de acceso de cliente solo es compatible desde las versiones más recientes del rol de servidor Acceso de clientes (Exchange 2010) a versiones más antiguas del rol del servidor Acceso de clientes (Exchange 2007) y no a la inversa.

Orden de los roles de servidor para actualizar

En el primer sitio o sitios de Active Directory que actualice, el primer rol de servidor de Exchange 2010 que se instala es el rol de servidor Acceso de clientes. Recomendamos que actualice un único sitio de Active Directory a Exchange 2010 al mismo tiempo. Según el tamaño de su sitio Active Directory, debería ser un único equipo de servidor de acceso de cliente o una matriz con equilibrio de carga de los equipos de servidor de acceso de cliente de Exchange 2010.

Se recomienda el orden siguiente para la instalación de roles de servidor de Exchange 2010:

1. Rol de servidor Acceso de clientes

2. Rol del servidor Transporte de concentradores

3. Rol de servidor Mensajería unificada (MU)

4. Rol de servidor Buzón de correo

NOTA:

Al actualizar a Exchange 2010, no puede realizar una actualización de servidor in situ de un servidor de Exchange existente.

Más tarde se puede agregar el rol de servidor Mensajería unificada, o si desea instalarla al mismo tiempo que otros roles de servidor, debe seleccionar Instalación personalizada de Exchange Server.

NOTA:

Debe implementar el rol de servidor Transporte perimetral en la red perimetral y fuera del bosque de Active Directory

Diferencias de administración Microsoft Exchange Server 2010

La Consola de administración de Exchange (EMC) está disponible en Exchange Server 2010 y Exchange Server 2007. A continuación, se enumeran las tareas y las acciones que pueden realizarse con la EMC en Exchange 2010 o Exchange 2007:

· Las acciones que crean objetos, como un nuevo buzón o una nueva libreta de direcciones sin conexión (OAB), solamente se pueden llevar a cabo en una versión de la EMC que sea igual a la del objeto de destino. Por ejemplo, para crear un buzón en un servidor de buzones de Exchange 2007, debe usarse la EMC en Exchange 2007. Se aplica lo siguiente:

o Las bases de datos de buzones de Exchange 2007 no pueden ser administradas por la EMC en Exchange 2010, aunque sí pueden verse.

o La EMC en Exchange 2010 no puede habilitar ni deshabilitar los buzones de mensajería unificada de Exchange 2007.

o La EMC en Exchange 2010 no puede administrar dispositivos móviles de Exchange 2007.

· Las acciones que requieren la visualización de objetos pueden realizarse desde cualquier versión de la EMC a cualquier versión de objetos de Exchange, con algunas excepciones:

o Los objetos de regla de transporte de Exchange 2010 y Exchange 2007 solo pueden ser visualizados desde la versión correspondiente de la EMC.

o Los servidores de Exchange 2010 y Exchange 2007 solo pueden visualizarse en la versión correspondiente de la EMC.

o La herramienta Visor de cola de la EMC en Exchange 2010 no se puede conectar con un servidor de Exchange 2007 para ver las colas o los mensajes.

NOTA:

Si un objeto de Exchange 2007 (por ejemplo, un grupo de almacenamiento) no se encuentra en Exchange 2010, no hay interoperabilidad esperada ni proporcionada, ya que Exchange 2010 no tiene constancia de la característica.

o No puede usar las tareas de configuración de seguimiento de mensajes entre Exchange 2010 y Exchange 2007. Debe usar las herramientas de seguimiento de mensajes de Exchange 2007 en los servidores Exchange 2007 y las herramientas de seguimiento de mensajes de Exchange 2010 en los servidores Exchange 2010.

Coexistencia del rol de servidor Microsoft Exchange Server 2003

En esta sección se proporcionan detalles acerca de cada rol de servidor de Exchange 2010 en un escenario de coexistencia.

Coexistencia del servidor de acceso de cliente

El rol de servidor de acceso de cliente proporciona nuevas características además de toda la funcionalidad proporcionada por un servidor front-end en Exchange 2003. Toda la conectividad de cliente (incluida la conectividad MAPI de Microsoft Outlook) ahora funciona mediante el rol de servidor de acceso de cliente. Los clientes ya no se conectan directamente al rol de servidor de buzón. El rol de servidor Acceso de clientes puede coexistir con servidores de Exchange 2003. En la siguiente lista se describen las dependencias y los requisitos del servidor de acceso de cliente de Exchange 2010 para la coexistencia con Exchange 2003:

· El hecho de que el usuario consulte el cliente de Outlook Web App de Exchange 2003 o el cliente de Outlook Web App de Exchange 2010 depende de la ubicación de su buzón. Por ejemplo, si el buzón se encuentra en un servidor back-end de Exchange 2003 y en el servidor de acceso de cliente se ejecuta Exchange 2010, el usuario verá Outlook Web Access, el cliente de Exchange 2003.

· La versión de Exchange ActiveSync que usen los clientes depende de la versión del servidor en que se encuentra el buzón del cliente. El buzón del usuario debe ubicarse en un servidor que ejecute Exchange 2003 SP2 o Exchange 2010 para que Direct Push se habilite para Exchange ActiveSync.

· Al realizar una actualización de Exchange 2003 a Exchange 2010, normalmente se actualizan todos los servidores de Exchange de un grupo de enrutamiento o sitio de Active Directory específico a Exchange 2010 a la vez, se configura la coexistencia y, a continuación, se actualiza el sitio siguiente.

Importante:

Al actualizar una organización de Exchange 2003, se requiere un servidor front-end de Exchange 2003 compatible con la actualización. Para cada servidor de acceso de cliente de Exchange 2010, solo se puede configurar una dirección URL de Outlook Web Access 2003 para redireccionamiento. Para ello, se necesita un único servidor front-end de Exchange 2003 o una matriz con equilibrio de carga de los servidores front-end de Exchange 2003.

Para obtener más información acerca de la coexistencia del servidor de acceso de cliente entre Exchange 2003 y Exchange 2010, y para obtener información sobre las nuevas características de Exchange 2010, consulte Actualizar desde el servicio de acceso de cliente de Exchange 2003.

Exchange 2007 introdujo los servicios Detección automática y Disponibilidad, y Exchange 2010 continúa dependiendo de estos servicios:

· El servicio Detección automática configura equipos cliente que ejecutan Microsoft Outlook 2010, Outlook 2007, Entourage y otras aplicaciones cliente. El servicio Detección automática también puede configurar dispositivos móviles compatibles. El servicio Detección automática permite el acceso a las características de Exchange a los clientes de Outlook 2010 que están conectados al entorno de mensajería de Exchange.

· El servicio Disponibilidad mejora la experiencia de calendario y planeación de reuniones de los trabajadores de información facilitando información de disponibilidad segura, coherente y actualizada a los equipos que ejecutan Outlook 2007 o Outlook 2010.

Coexistencia del servidor Transporte de concentradores

El rol del servidor Transporte de concentradores está diseñada para administrar todo el flujo de correos de la organización de Exchange. También es responsable de administrar las reglas de transporte, las directivas de registro en el diario y la entrega de mensajes. Este servidor se implementa en el bosque de Active Directory y es necesario para que los buzones de Exchange 2010 envíen y reciban mensajes. El servidor Transporte de concentradores retransmite los mensajes que se envían a Internet al rol de servidor Transporte perimetral o a un host inteligente de terceros.

Puede agregar un servidor Transporte de concentradores de Exchange 2010 a una organización de Exchange existente después de implementar de manera satisfactoria los servidores de acceso de cliente de Exchange 2010. Cuando se introducen los servidores Transporte de concentradores de Exchange 2010 en su entorno de Exchange 2003, todos los servidores Transporte de concentradores de Exchange 2010 se colocan en un grupo de enrutamiento único y separado.

Para habilitar el flujo de correo entre la implementación de Exchange 2010 y la organización de Exchange 2003 existente, debe crear un conector de grupo de enrutamiento. Este conector grupo de enrutamiento se crea durante la instalación del primer servidor Transporte de concentradores de Exchange 2010.

Coexistencia del servidor de buzones

Para que coexistan los servidores de buzones de Exchange 2010 y Exchange 2003, se debe poder enviar correo entre los buzones. Exchange 2010 usa el servidor Transporte de concentradores para enviar correo. Es necesario implementar un servidor Transporte de concentradores de Exchange 2010 en cada sitio de Active Directory que contenga un servidor de buzones de Exchange 2010. Además, se necesita un servidor de acceso de cliente en cada sitio de Active Directory en el que existe un servidor de buzón. Si mueve un buzón desde Exchange 2003 a Exchange 2010, y el buzón forma parte de una directiva de direcciones de correo electrónico, las direcciones de dicho buzón se actualizarán automáticamente según la configuración de la directiva de direcciones de correo electrónico. Si el buzón tenía una dirección SMTP principal diferente de la dirección de correo electrónico impuesta por la directiva, la dirección SMTP principal se convertirá en secundaria y la dirección generada por la directiva se convertirá en la dirección SMTP principal.

Puede replicar los datos de las carpetas públicas entre las bases de datos de las carpetas públicas de Exchange 2010 y Exchange 2003. Para ello, se debe crear una réplica de la carpeta pública mediante el uso del Administrador del sistema de Exchange 2003 Exchange.

Coexistencia del servidor Mensajería unificada

El rol de servidor Mensajería unificada está diseñado para proporcionar mensajería unificada para destinatarios de Exchange 2010. La mensajería unificada aúna mensajes de voz y de correo electrónico en un almacén al que se puede tener acceso desde un teléfono, el equipo de un usuario o un dispositivo móvil. Los usuarios pueden tener acceso a los mensajes de voz, al correo electrónico y a la información de calendario de su buzón de Exchange 2010 desde clientes de correo electrónico como, por ejemplo, Outlook y Outlook Web App.

La función del servidor Mensajería unificada depende de las funciones de servidor Transporte de concentradores y Buzón de correo. Todo el correo SMTP enviado desde un servidor Mensajería unificada debe enviarse a un servidor Transporte de concentradores de Exchange 2010. Para que los destinatarios puedan usar la mensajería unificada deben tener un buzón de Exchange 2010.

Las versiones de Exchange anteriores a Exchange 2007 no se pueden actualizar y usted debe implementar una organización de Exchange 2010 con todos los roles de servidor de Exchange, incluida la mensajería unificada, y después mover los buzones de Exchange 2003 (o versiones anteriores) a un servidor de buzones de Exchange 2010.

Coexistencia del servidor de transporte perimetral

La función del servidor Transporte perimetral está diseñada para mejorar la protección antivirus y frente al correo no deseado en la organización de Exchange. El servidor de transporte perimetral, además, aplica directivas a los mensajes que se envían de unas organizaciones a otras. Esta función de servidor se implementa en la red perimetral y fuera del bosque de Active Directory. El servidor Transporte perimetral se puede implementar como host inteligente y servidor de retransmisión SMTP en una organización de Exchange 2003 existente.

Puede agregar un servidor de transporte perimetral a cualquier organización de Exchange existente sin actualizar los servidores internos de Exchange ni tener que hacer ningún cambio en la organización. Tampoco hay que llevar a cabo ninguna preparación de Active Directory al instalar el servidor Transporte perimetral.

Si usa el Filtro inteligente de mensajes de Exchange en Exchange 2003 para realizar tareas de protección contra correo no deseado, puede usar el servidor Transporte perimetral para agregar un nivel adicional de protección. El servidor de transporte perimetral ofrece protección contra virus y correo no deseado cuando los mensajes llegan a la red.

Si se implementa un servidor Transporte perimetral en Exchange 2010 para que sea compatible con una organización de Exchange que aún no haya implementado Exchange 2010, solo habrá disponible un grupo limitado de características. En este caso, no se puede crear una suscripción perimetral. En consecuencia, no se puede usar la búsqueda de destinatarios ni la agregación de listas seguras.

NLB Microsoft

2012-07-03T16:32:00.001+02:00

NOTA: Se debe de tener en cuenta que si hacemos un NLB, debemos crear los registros manualmente en el DNS, adicionalmente debemos tener en cuenta las recomendaciones de los fabricantes de Firewall y Routers ya que NLB, no sigue las normas en la creación de las MAC-Address Virtuales para las interfaces VIP, para entender como realizar la creación de entradas manuales en la tabla ARP de nuestro Router debemos seguir el siguiente procedimiento.

Ejemplo de configuración de un Switch Cisco para el soporte de NLB.

Primero debemos entender que es UNICAST y MULTICAST, para ello daremos una breve explicación de los dos tipos de NLB que podremos crear.

UNICAST

Esta es la opción por defecto y es la opción recomendada. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, y la dirección MAC de cada tarjeta de red NO es utilizada. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene una única dirección MAC, en particular, la MAC del Cluster. Así, tanto la dirección IP del Cluster como la dirección IP propia de la tarjeta de Red, se resuelven a la dirección MAC del Cluster, ya que se sobrescribe la dirección MAC real de las tarjetas de red del Cluster NLB con la dirección MAC del Cluster.

Esta configuración, implica que NO es posible la comunicación desde un Host del Cluster NLB a otro Host del Cluster NLB a través de la tarjeta de red utilizada en el Cluster, debido a que al compartir la dirección MAC (es decir, utilizar la misma dirección MAC en el equipo de origen y en la tarjeta de red del equipo destino), se produce una confusión, es decir, en el nivel de enlace OSI (Ethernet y direcciones MAC) no es posible diferenciar al destinatario del emisor, y por ello, la comunicación host-to-host (también conocida como intra-host) NO es posible.

Es interesante recordar (para aquellos pocos que lo puedan utilizar) que al utilizar Application Center 2000 para configurar NLB, se especificará el modo de operación del Cluster NLB en Unicast, conforme indicar el artículo de soporte KB 278431.

MULTICAST

La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, pero de forma adicional, cada tarjeta de red mantiene su dirección MAC. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene dos direcciones MAC, pero sólo la dirección MAC del Cluster es utilizada para la comunicación con los equipos clientes. Así, la dirección IP del Cluster se resuelve a la dirección MAC del Cluster, y la dirección IP propia de la tarjeta de Red se resuelve a la dirección MAC propia de dicha tarjeta.

Este comportamiento implica que una tarjeta de Red de un Cluster NLB configurado en modo de operación Multicast, es capaz de manejar tanto el tráfico de los clientes (paquetes destinados a la dirección IP/MAC del Cluster) como el tráfico propio del Host (paquetes destinados a la dirección IP/MAC de la tarjeta de Red del Cluster NLB).

En algunos casos la utilización de direcciones MAC multicast, no es soportada por la implementación ARP de algunos enrutadores (routers), como es el caso de Cisco (ni más ni menos ;-), en cuyo caso, el Cluster NLB no será visible fuera del segmento Ethernet al que pertenece. Para evitar este tipo de problemas, debe garantizarse que el enrutador (Router) acepta respuestas ARP que incluyan una dirección MAC en el payload de la trama Ethernet, pero que parecen proceder de un dispositivo con una dirección MAC distinta, conforme se muestra en la cabecera Ethernet. Si el enrutador (router) o el conmutador multi-capa (multi-layer switch) correspondiente no soporta esta funcionalidad, es posible crear una entrada ARP estática en el router como solución al problema, para que así sea capaz de resolver la dirección IP Unicast a la dirección MAC Multicast correspondiente.

Multicast puede ofrecer un rendimiento inferior a Unicast, debido a que utiliza una única tarjeta de red tanto para el tráfico de los equipos clientes como para el tráfico host-to-host (también conocido como tráfico intra-host).

Al utilizar Multicast es posible activar la opción IGMP Multicast. La principal razón por la que activar o desactivar la opción IGMP Multicast, es en caso de descubrir algún tipo de problema de funcionamiento, como por ejemplo, problemas de convergencia.

Unas Vez explicado las opciones del NLB, procederemos a la configuración en el Switch, para ponernos en antecedentes explicaremos el entorno de Ejemplo.

La red se componen un Switch Cisco y dos equipos Windows con un NLB MULTICAST, con una IP virtual 172.16.241

Configuración Realizada en Catalyst 6509

Cat6K#show running-config

Building configuration...

version 12.1

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

hostname Cat6K

boot buffersize 126968

boot system flash slot0:c6sup11-jsv-mz.121-8a.E.bin

redundancy

main-cpu

auto-sync standard

ip subnet-zero

interface GigabitEthernet1/1

no ip address

shutdown

interface GigabitEthernet1/2

no ip address

shutdown

interface FastEthernet2/1

description "Uplink to the Default Gateway"

no ip address

switchport

switchport access vlan 100

interface FastEthernet2/2

no ip address

shutdown

interface FastEthernet2/3

description "Connection to Microsoft server"

no ip address

switchport

switchport access vlan 200

interface FastEthernet2/4

description "Connection to Microsoft server"

no ip address

switchport

switchport access vlan 200

interface FastEthernet2/5

no ip address

shutdown

interface FastEthernet2/48

no ip address

shutdown

interface Vlan1

no ip address

shutdown

mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4 disable-snooping

! --- Creación de una entrada estática en el interruptor para el MAC de multidifusión virtual.

! --- fa2/3 Y fa2/4 son los puertos conectados al servidor.

!--- El desactivar snooping es aplicable sólo para switches de la serie Cisco Catalyst 6000/6500

arp 172.16.63.241 0300.5e11.1111

! --- 172.16.63.241 es la dirección IP virtual de los 2 servidores

interface Vlan100

ip address 172.17.63.240 255.255.255.192

!--- Vlan Del lado cliente

interface Vlan200

ip address 10.1.1.250 255.255.255.0

!--- Vlan Del lado Servidores

!--- Importante: Configure la puerta de enlace predeterminada

!--- del servidor de Microsoft a esta dirección.

ip classless

ip route 0.0.0.0 0.0.0.0 172.16.63.193

no ip http server

line con 0

line vty 0 4

login

End

Configurando proveedores gratuitos de Spam

2012-07-03T14:37:00.001+02:00

estos proveedores de spam se basan muchas veces por denuncias, y reclamaciones de los usuarios, a continuación debéis abrir el PowerShell de vuestro edge Transport y pegar los siguientes comandos.

Add-IPBlockListProvider -Name "Spam and Open Relay Blocking System (SORBS) IP Block List Provider" -LookupDomain "dnsbl.sorbs.net"
Add-IPBlockListProvider -Name "SpamCop Blocking List (SCBL)IP Block List Provider" -LookupDomain "bl.spamcop.net"
Add-IPBlockListProvider -Name "Not Just Another Bogus List (NJABL.ORG)IP Block List Provider" -LookupDomain "dnsbl.njabl.org"
Add-IPBlockListProvider -Name "Composite Blocking List (CBL)IP Block List Provider" -LookupDomain "cbl.abuseat.org"
Add-IPBlockListProvider -Name "SpamHaus IP Block List Provider" -LookupDomain "zen.spamhaus.org"
Add-IPBlockListProvider -Name "Surriel IP Block List Provider" -LookupDomain "psbl.surriel.com"
Add-IPBlockListProvider -Name "BarracudaCentral IP Block List Provider" -LookupDomain "bb.barracudacentral.org"
Add-IPBlockListProvider -Name "Manitu IP Block List Provider" -LookupDomain "ix.dnsbl.manitu.net"
Add-IPAllowListProvider -Name "Spamhaus IP Allow List Provider" -LookupDomain "swl.spamhaus.org" -AnyMatch $true
Add-IPAllowListProvider -Name "Isipp IP Allow List Provider" -LookupDomain "iadb.isipp.com" -AnyMatch $true
Add-IPAllowListProvider -Name "Bondedsender IP Allow List Provider" -LookupDomain "query.bondedsender.org" -AnyMatch $true
Add-IPAllowListProvider -Name "Habeas IP Allow List Provider" -LookupDomain "hul.habeas.com" -AnyMatch $true

Con esto se configurara todos los proveedores gratuitos

Como importar los pre requisitos para cada rol de Exchange

2012-07-03T14:36:00.001+02:00

Antes de Instalar Exchange debemos importar los prerrequisitos del sistema operativa para cada rol tenemos unas caracteristicas que necesitas.

Lo Primero que debemos hacer es Abrir el PowerShell en modo Administrador, y los siguientes comando dependiendo del rol que necesitemos instalar.

Client Access

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart

HUB Transport

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart

Mail Box

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart

Unified Messaging

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart

Edge Transport

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart

A continuación Roles Combinados.

Client Access, Hub Transport, and Mailbox

Import-Module ServerManager

Client Access, Hub Transport, Mailbox, and Unified Messaging

Import-Module ServerManager

Client Access and Hub Transport

Import-Module ServerManager

Con esto automáticamente instalaremos los prerrequisitos y se reiniciara el servidor de ser necesario.

Cambiar el valor por defecto de la Cookies de OWA, Privado y Publica

2012-07-03T14:35:00.001+02:00

los valores por defecto de estas cookies son las siguientes:

Publica 5 minutos.
Privada 15 Minutos.

si queremos cambiar estos valores solo tentremos que ir al cas correspondiente y seleccionar el editor de registro con la siguiente ruta.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

y dentro de esta ruta tendremos dos llaves

PublicTimeout
PrivateTimeout

No te preocupes si no existen, ya que si tienes los valores por defecto es posible que no existan, para ello solo tendrás que crearlas son de Tipo DWORD, y el valor siempre lo debemos poner en minutos.

Como subir el schema master Exchange 2010

2012-03-28T15:03:00.001+02:00

Para Actualizar el dominio, debemos insertar, el DVD de Exchange 2010, en el servidor de Schema master, debemos realizar el siguiente procedimiento, para poder actualizar el Schema de nuestra organización.

Como se tiene algún servidor de Exchange 2003 en nuestra organización, debemos ejecutar: “setup /PrepareLegacyExchangePermissions: DOMAIN.COM” o “setup /pl DOMAIN.COM“ Hay que pertenecer al grupo ‘Administradores de Organización’ o ‘Enterprise Admins’ de cada dominio para poder ejecutar el comando. Con esto prepararemos los permisos de Exchange heredados para Microsoft Exchange 2010.

Tenemos que esperar a que la réplica se haga efectiva en los controladores de dominio, continuamos con la ampliación del esquema de Active Directory: “setup /PrepareSchema” o “setup /ps” (no ejecutaremos este comando si no vamos a ejecutar /PrepareAD en nuestro bosque). Hay que pertenecer a los grupos ‘Administradores de Esquema’ o ‘Schema Admins’ y ‘Administradores de Organización’ o ‘Enterprise Admins’ para poder ejecutar el comando.

Ejecutaremos “setup /PrepareAD /OrganizationName: ORGANIZACION” o “setup /p /on:ORGANIZACION” para preparar la organización. Este paso también prepararía el dominio local. Hay que pertenecer al grupo ‘Administradores de Organización’ o ‘Enterprise Admins’ para poder ejecutar el comando.

Ejecutamos “setup /PrepareDomain DOMAIN:COM” o “setup /pd trabajo.lab” (Ilustración 3)para preparar el dominio local o el que se indique. O directamente ejecutaremos: “setup /PrepareAllDomains” o “setup /pad” para preparar todos los dominios de nuestra organización. No tendríamos que ejecutar este comando si hemos ejecutado /PrepareAD en el dominio. Para ejecutar /PrepareDomain o /dp habria que pertenecer al grupo ‘Administradores de Organización’ o ‘Enterprise Admins‘; y para ejecutar el comando en un único dominio bastaría con ser miembros de ‘Administradores de Dominio’ o ‘Domain Admins’.

Uno de los factores a tener en cuenta y que tiende a dar problemas, es que en nuestra organización no tengamos nuestros DC en Windows x64, y en el caso del Schema master, cuando subimos el nivel del schema, para ello debemos ir al servidor con el rol que si fuera un i386 debemos realizarlo de la siguiente manera:

support\adprep\adprep32.exe /forestprep
support\adprep\adprep32.exe /ADprep

como limpiar un Exchange Server muerto del directorio Activo

2012-03-27T09:34:00.001+02:00

hoy mostrare como podemos limpiar un el directorio activo, de nuestra organización, en el caso de que nuestro servidor de Exchange no responda, o este muerto.

para ello debemos abrir ADSI Edit

boton de la derecha –> Settings

Seleccionaremos Configuración

y en la ruta

Configuration/Services/Microsoft Exchange/[My Exchange Org]/First Administrative Group/Servers.

Eliminaremos los servidores muertos, y en Databases, eliminaremos las bases de datos de dicho servidor en el caso de que el servidor dispuesto no estuviera en HA.

Puertos que se deben balancear para la implementación de ms exchange server 2010 con el ROL de CAS usando servicio de nlb

2012-03-06T13:39:00.001+01:00

Protocol	TCP port numbers
HTTPS	443
IMAP4	143 and 993
POP3	110 and 995
RPC Endpoint Mapper	135
Address Book service	59595
RPC Client Access service	59596

Alta disponibilidad en Ms Exchange server 2010 con el rol de cas

2012-03-06T13:37:00.001+01:00

adicionalmente y después de instalar y configurar el nlb, y el MS Exchange Server 2010, debemos seguir el siguiente procedimiento para la configuración del ARRAY CAS.

Para poder hacer que el client Access y el libro de direcciones esté disponible en alta disponibles:

· Se deben agregar las siguientes llaves del registro.

o En HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC

o Click derecho MSExchangeRPC, Crear nueva llave.

o escribimos ParametersSystem.

o derecho ParametersSystem, seleccionamos New, y luego click DWORD (32-bit) Value.

o escribimos TCP/IP Port.

o Doble-click TCP/IP Port.

o escribimos 59595 OK.

· Se deben agregar las siguientes llaves del registro.

o En HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeAB

o Click derecho MSExchangeAB, Crear nueva llave.

o escribimos Parameters.

o derecho Parameters, seleccionamos New, y luego click String Value.

o escribimos RpcTcpPort.

o Doble-click RpcTcpPort.

o escribimos 59596 OK.

Adicionalmente debemos ejecutar en el PowerShell Exchange la siguiente liniea de comando para configurar el Array del CAS

New-ClientAccessArray -Fqdn cas2010.url-interna.local <FQDN of CAS load balanced array> –Site Defaul-First-site<Active Directory Site>

Instalación de los Prerrequisitos del Servidor de Exchange 2010 CAS

2012-03-06T13:34:00.001+01:00

Para la instalación de los prerrequisitos iniciaremos la consola del PowerShell y le daremos los siguientes comandos.

Import-Module ServerManager

Después de reiniciar los servidores se debe de habilitar el servicio de .net TCP Port Sharing.

Set-Service NetTcpPortSharing -StartupType Automatic

como se debe de cambiar los flujos de correo en una migración

2012-03-06T13:33:00.001+01:00

La función del servidor HUB Transport está diseñada para manejar todo el flujo de correo para la organización de MS Exchange. También es responsable de manejar las reglas de transporte, las políticas de diario y la entrega de mensajes. Este servidor está implementado en el bosque de Active Directory y se requiere para los buzones de MS Exchange Server 2010 para enviar y recibir mensajes. Los mensajes enviados a la Internet se transmiten por el servidor de transporte perimetral en el servidor de transporte perimetral (EDGE).

Se puede añadir un servidor de MS Exchange Server 2010 Transporte de concentradores en una organización existente de Exchange después de desplegar con éxito servidores de Exchange 2010 de acceso de cliente. Después de introducir servidores de MS Exchange Server 2010 de HUB Transport a su entorno de Exchange 2007, todavía los necesitaremos para mantener los servidores de MS Exchange Server 2007 HUB Transport. Los servidores de MS Exchange Server 2010 buzones de correo sólo pueden comunicarse con servidores de Exchange 2010 Transporte de concentradores y servidores de buzones de Exchange 2007 sólo puede comunicarse con servidores de MS Exchange Server 2007 HUB Transport. Cuando se envía un mensaje de un buzón en un servidor de buzones de MS Exchange Server 2010 a un buzón en un servidor de buzones de MS Exchange Server 2007, el mensaje se presentó por primera vez al Servidor más cercano de MS Exchange Server 2010 HUB Trasnport en el sitio. Este servidor retransmite el mensaje a un servidor de MS Exchange Server 2007 HUB Transport en el mismo sitio, que finalmente entrega el mensaje al servidor de buzones de MS Exchange Server 2007.

· Se debe Subscribirse los servidores de transporte perimetral EDGE a la organización de Exchange. Esto permitirá que el flujo de mensajes de Internet a través de Exchange 2010 HUB Transport y EDGE.

o Crearemos un archivo de suscripción perimetral en un servidor de transporte perimetral EDGE.

o Importar un archivo de suscripción perimetral a un sitio de Active Directory.

· Retire el conector SMTP de Exchange 2003 que se utiliza para manejar el correo de Internet. Su cuenta debe ser miembro del grupo local Administradores y miembro de un grupo que ha tenido la función Administrador de Exchange en el nivel de grupo administrativo.

o En Exchange System Manager, expanda el nodo de organización, expanda Grupos administrativos, expanda <AdministrativeGroupName>, Grupos de enrutamiento, expanda <RoutingGroupName>, a continuación, seleccione Conector.

o En el panel de la derecha, haga clic en el conector que desea eliminar y seleccione Eliminar.

· Click clic en Aceptar para confirmar la eliminación.

Pasos para la configuración de un servidor de CAS 2010

2012-03-06T13:29:00.001+01:00

· Ya que organización necesita tener acceso a Microsoft-Server-ActiveSync, habilitar Microsoft-Server-ActiveSync, como se muestra en el siguiente ejemplo.

Enable-OutlookAnywhere-servidor: <CAS2010>-ExternalHostname: URL.externa.com -SSLOffloading $ false

· Se debe configurar un espacio de nombres externo principal durante la instalación, configurar los directorios virtuales de la libreta de direcciones sin conexión (OAB), servicios web de Exchange, Microsoft Exchange ActiveSync, Microsoft Office Outlook Web Access y Exchange Panel de Control (PAC), como se muestra en los siguientes ejemplos.

Ejemplo configura los directorios virtuales de la OAB.

Set-OABVirtualDirectory <CAS2010> \ OAB *-ExternalUrl "https://URL.externa.com/OAB"

Ejemplo configura los directorios virtuales de servicios web de Exchange.

Set-WebServicesVirtualDirectory <CAS2010> \ * EWS-ExternalUrl https://URL.externa.com/ews/exchange.asmx

Ejemplo configura los directorios virtuales de Exchange ActiveSync.

Set-ActiveSyncVirtualDirectory-Identidad <CAS2010> \ Microsoft-Server-ActiveSync-ExternalUrl "https://URL.externa.com"

Ejemplo configura los directorios virtuales para Outlook Web Access.

Set-OwaVirtualDirectory <CAS2010> \ OWA *-ExternalUrl https://URL.externa.com/OWA

Ejemplo configura los directorios virtuales para el ECP.

Set-EcpVirtualDirectory <CAS2010> \ * ECP-ExternalUrl https://URL.externa.com /ECP

· Para configurar el Outlook Web de la organización se deben de seguir los siguientes pasos.

o Para obtener la configuración de Outlook Web Access de Exchange Server 2007, ejecute el cmdlet Get-OwaVirtualDirectory.

o Para configurar las opciones de Outlook Web App en Exchange 2010, ejecute el cmdlet Set-OwaVirtualDirectory.

· Para cambiar la configuración de autenticación de ActiveSync.

o Para obtener la configuración de Exchange ActiveSync de su servidor de Exchange 2007, ejecute el cmdlet Get-ActiveSyncVirtualDirectory.

o Para configurar las opciones de Exchange ActiveSync en Exchange 2010, ejecute el cmdlet Set-ActiveSyncVirtualDirectory.

· Cambiar el servidor de generación de la OAB y permitir la distribución de Web en el servidor de Exchange 2010 Acceso de cliente que utiliza los pasos siguientes.

o Mover el OAB.

Move-OfflineAddressBook "Lista de direcciones sin conexión predeterminada"-Server <MBX2010>

o agregar el servidor de MS Exchange Server2010 Acceso de cliente como punto de distribución Web.

$ OABVDir = Get-OABVirtualDirectory-Server <CAS2010>

$ OAB = Get-OfflineAddressBook "Lista de direcciones sin conexión predeterminada"

$ OAB.VirtualDirectories + = $ OABVdir.DistinguishedName

Set-OfflineAddressBook "Lista de direcciones sin conexión predeterminada", VirtualDirectories $OAB.VirtualDirectories

Importante:

No use el Administrador de IIS para cambiar la configuración de autenticación en el directorio virtual de ActiveSync de Microsoft, ya que el proceso DS2MB en el Powershell de Exchange sobrescribe la configuración almacenada en Active Directory.

· Crearan un legado de un nombre de host en su sistema externo de Nombres de Dominio (DNS) y asociar este nombre de host con el servidor de Exchange 2007 Acceso de cliente o con la infraestructura de su servidor proxy. Consulte "Creación de un nombre de host Legacy" en otro articulo explicaremos con mas detalles este tema.

Una vez realizado este procedimiento se deberán realizar las configuraciones oportunas para cambiar el punto de acceso desde internet, en los Firewall correspondientes.

Procedimiento de migración de MS Exchange 2007 a MS exchange server 2010

2012-03-06T13:23:00.001+01:00

Para el proceso de migración de debe seguir la siguiente secuencia para una migración desde Exchange 2007 a Exchange 2010 es el siguiente:

1. Actualice todos los servidores de Exchange a Exchange Server 2007 Service Pack 2 (Se recomienda la instalación del Service Pack 3).

2. Llevar el bosque de AD y los dominios de Windows Server 2003 Funcional (o más) niveles.

3. Actualiza por lo menos un controlador de dominio de catálogo global en cada sitio que albergará AD Exchange Server a Windows Server 2003 SP2 o superior.

4. Prepare un equipo Windows Server 2008 (RTM o R2) servidor de edición de 64 bits para el primer intercambio Server 2010.

5. Instalar las herramientas de LDIFDE AD en el nuevo servidor de Exchange 2010 (para actualizar el esquema).

6. Instale los requisitos previos necesarios (WWW para la función del servidor CAS).

7. Ejecutar la instalación en el servidor de Exchange 2010, actualizar el esquema, y preparar el bosque y los dominios. (La instalación se ejecuta en un solo paso o por separado en la línea de comandos.)

8. Instalación de servidores CAS función de servidor y configurar por el diseño establecido 2010. Validar la funcionalidad.

9. Transferencia de OWA, ActiveSync y Outlook en cualquier lugar de tránsito a los nuevos servidores CAS.

10. Instale papel de HUB y configure por diseño 2010.

11. La transferencia de tráfico de correo entrante y saliente en el 2010 los servidores de HT.

12. Instalar y configurar servidores de buzones de bases de datos (DAG si es necesario).

13. Crear réplicas de carpetas públicas en servidores de Exchange 2010 con AddReplicatoPFRe-cursive.ps1 o herramienta de Exchange 2010 de carpetas públicas.

14. Mueva los buzones de Exchange 2010 mediante el Asistente para mover buzón o Powershell.

15. Volver a asignar la Libreta de direcciones sin conexión (OAB), servidor de generación de Exchange Server 2010.

16. Transferencia de todas las réplicas de carpetas públicas de Exchange Server 2010 almacén de carpetas públicas.

17. Eliminar almacenes de información públicos y privados del servidor de Exchange 2007 (s).

18. Desinstalar todos los servidores de Exchange 2007.

Una de las áreas de cambio que se debe tomar en cuenta en la transición a Exchange 2010 que es diferente que en su implementación de Exchange 2007 es la alta disponibilidad y funciones de recuperación de desastres en la función del servidor Buzón. Porque los conceptos de clústeres de copia única, replicación continua en clúster (CCR), y Replicación continua en espera (SCR) ya no existen en Exchange 2010, en la transición de sus buzones de correo de Exchange 2007 que tiene las siguientes funciones de Exchange 2010 que la base de datos de Grupos de usuarios en disponibilidad (DAG). Por supuesto, si son sólo la migración a un servidor de buzones de Exchange 2010 sin una sola en alta disponibilidad o recuperación de desastres, a continuación, sólo tendrá bases de datos de buzones que se le mueven sus buzones de correo a otro. Sin embargo, para las organizaciones ejecutoras de alta disponibilidad y recuperación ante desastres, el DAG proporcionar la replicación de correo electrónico (de hasta 16 copias) de un servidor a otro. Cuando la configuración de su buzón de servidores de Exchange 2010 para prepararse para la transición de buzones de correo, la configuración de replicación DAG y poner a prueba su conmutación por error y conmutación por recuperación de los servidores de buzones de Exchange 2010, y luego mover los buzones al DAG.

Otra área de cambio entre Exchange 2007 y Exchange 2010 es que todas las conexiones de clientes a través del servidor CAS. A diferencia de Exchange 2007 y antes de que las conexiones OWA fue a través del servidor CAS pero Outlook (2003/2007) establece las conexiones directamente a través de MAPI para los servidores de buzones back-end. Sin embargo, con Exchange 2010, los sistemas cliente ya no se comunican directamente con los servidores de buzones back-end. En cambio, las conexiones de cliente MAPI contra el servidor CAS que se comunican con los servidores de buzones en el servidor. Así que al igual que en el cambio de servidores de transporte perimetral de Exchange 2007 en todas las rutas de correo a través de los servidores de HUB (los correos entrantes, salientes, de usuario a usuario de correo entre los servidores, e incluso para el usuario de correo de usuario entre los usuarios en el mismo servidor), con Exchange 2010, todos los clientes a través del servidor CAS. Por lo tanto, los servidores CAS tomar más de una carga de rendimiento y tienen que ser reforzado un poco. Nuestras recomendaciones para el CAS de buzones de Exchange 2007 es un servidor CAS de cada dos servidores de buzones. Para Exchange 2010, nuestra recomendación es de 3 servidores CAS de cada 4 servidores de buzones. La mayoría de organizaciones tienen por lo menos dos servidores CAS en su entorno para la redundancia, y porque se puede virtualizar la función CAS Plus tienen 2000, 3000, hasta 5.000 buzones de correo en un servidor de buzones individuales, que suelen encontrar este CAS 03:04: MBX relación sido sensacional para las organizaciones en términos de un cambio de diseño.

También es importante destacar que todas las funciones de servidor (CAS, HUB, Buzón de correo) en Exchange 2007 deben permanecer hasta que todos los usuarios se migran a Exchange 2010. Exchange 2010 CAS, HUB y servidores de buzones no son compatibles con Exchange 2007, así que para que un usuario pueda acceder a Outlook Web Access en Exchange 2007, Sera necesario que se conecte a uno de los servidores Exchange 2007 CAS para acceder a su buzón de correo en 2007 del servidor de buzones. Después de que su buzón se migra a Exchange 2010, el usuario llegará al servidor de Exchange 2010 CAS y el acceso a sus buzones de correo en el servidor de buzones de Exchange 2010. Debido a que Exchange 2010 tiene un servicio de proxy en el servidor CAS, la dirección URL externa para OWA puede apuntar a la CAS de Exchange Server 2010 y si el buzón del usuario está todavía en Exchange 2007, el servidor CAS/2010 pasará automáticamente la conexión del cliente a la CAS / 2007 del servidor de OWA.

Por último, pero no menos importante, después de mover buzones fuera de Exchange 2007 a Exchange 2010, Exchange 2007 debe de salir de la infraestructura necesaria para unas dos semanas. Al dejar el antiguo servidor de Exchange 2007 en su lugar, cuando un cliente de Outlook intenta conectarse al buzón del Server 2007 para su correo, el antiguo servidor de Exchange 2007 se notificará a los software de cliente de Outlook que el correo del usuario se ha trasladado a los Exchange Server 2010 y se actualizará automáticamente el perfil del usuario de Outlook con la información de destino del nuevo servidor. A partir de entonces, cuando el cliente de Outlook se pone en marcha, Outlook cambiara el acceso al buzón del usuario en el nuevo servidor de Exchange 2010. Al salir de esta infraestructura el cambio se llevara a cabo en un par de semanas, casi todos los usuarios que inicie el Outlook para que el perfil cambie automáticamente por lo que no requiere ninguna intervención del sistema cliente durante el proceso de migración. Los únicos usuarios que probablemente tendrá que reiniciar manualmente su perfil de Outlook son los usuarios que están en excedencia y que no había accedido a su correo de Outlook durante el tiempo de 2 semanas que tenía el entorno de Exchange 2007 sigue en pie.

Monitoreando vSphere con HP SIM

2012-03-06T13:16:00.001+01:00

HP System Insight Manager (HP SIM) se encarga de la supervisión de la infraestructura virtual. CLIENTE ha optado por utilizar Insight Manager y el MIB asociado que se va a instalar en cada host ESX como se muestra en el siguiente diagrama. SNMP deben estar habilitadas en la configuración de seguridad del cliente vSphere.

Monitoreando vSphere con HP SIM

Esto lo lograremos instalando el cliente VSphere en el HP SIM y Instalado el modulo de SIM VCENTER, que se encuentra en el DVD de instalación de HP SIM