Archivo

Entradas Etiquetadas ‘Configuración’

La serie SCCM 2007 R3 (III)

martes, 21 de febrero de 2012 Sin comentarios

Si el otro día realizamos la instalación de SCCM 2007 R3, hoy toca la configuración.

Los elementos imprescindibles a configurar están dentro de Site Settings en “Site Management” y son:

  • Client Agents
  • Boundaries
  • Client Installation
  • Discovery Methods
  • Software distribution

Empecemos, pues, por el primero

Client Agents

Dentro de Site Settings debemos definir el comportamiento de cada uno de los agentes de SCCM que instala el cliente “general”

Los diferentes agentes que tenemos son:

image

Cada uno de ellos realiza diferentes tareas y deberán configurarse en función del entorno y de lo que queremos que hagan.

Por ejemplo, si no hemos integrado WSUS en SCCM, el agente “Software Updates Client” no es necesario tenerlo activo.

image

 

Boundaries

Los boundaries definen los diferentes métodos que usarán los clientes de SCCM (los equipos, servidores, etc.) para localizar a su SCCM más cercano de modo que se pueda comunicar con él y trabajar correctamente.

Los boundaries se pueden definir de varias maneras:

  • IP subnet
  • Nombde de site de Active Directory
  • Prefijo IPv6
  • Rangos de IP
  • O cualquier combinación de los anteriores

Si todos nuestros equipos está dentro del AD y, por tanto, asociados a un Site del mismo, lo más adecuado es usar esta configuración para tener un control de los accesos a SCCM.

image

Client Installation

En este apartado se define la cuenta de instalación del cliente SCCM en los equipos, sobre qué tipos de equipo se realiza esa instalación y cómo, si de modo manual o automático.

image

image

Discovery Methods

SCCM tiene diferentes maneras de “localizar” equipos cliente

image

De todos ellos, el más usado es:

  • Active Directory System Discovery

Y un tercer método, Heartbeat Discovery que se encarga de comprobar si los equipos ya descubiertos siguen “vivos” en la red.

La configuración es muy simple, se crean diferentes rutas de búsqueda de equipos en el AD bien haciendo que examine todo el dominio (Local domain), todo el namespace del DNS (Local namespace) o consultas concretas a rutas donde tenemos los equipos clientes.

image

Una vez definidas, sólo debemos dejar que SCCM vaya descubriendo los equipos e instalando el agente.

Desde aquí

image

se acabará pasando a algo como

image

También es posible forzar la búsqueda de estos equiopos desde “Polling schedule” en “Run full discovery as soon as possible”

image

 

Software distribution

Finalmente, quedará definir los puntos de distribución de software

Esto se realiza en Component Configuration –> Software Distribution

image

Donde definiremos la unidad del sistema que contendrá los paquetes a distribuir

image

La cual creará una carpeta de nombre

image

En nuestra unidad E:\ y la compartirá para todos los usuarios de la red.

La siguiente entrada estará dedicada al fabuloso mundo de la paquetización de software para su posterior distribución por SCCM Smile

 

Saludos,

Marc

Categories: Dia a dia Tags: , ,

Migración de bosques AD: configuración de los HT en Exchange 2010 SP1

sábado, 10 de septiembre de 2011 Sin comentarios

Continuando con la configuración del nuevo entorno de Exchange iniciada con la de los CAS, procedermos a dejar “a nuestro gusto” el rol de HT.

1.1 Configuración de la organización

Los primeros pasos de configuración corresponden al nivel de organización Exchange.

Creamos un Send Connector para enviar todo el correo que no pertenezca a la organización Internet.

El conector tiene el mismo nombre que el existente actualmente en el entorno antiguo y es “Internet”.

Configuramos como SmartHosts los IronPort que hacen de applicance de envío de correo, servicio de anti-spam, etc.

image

Y añadimos como servidores origen de los envíos a ambos servidores CAS, cas1.midominio.local y cas2.midominio.local

image

Eliminamos la restricción del tamaño de envío de los correos, tal como está en el entorno a migrar.

image

Como dominio de correo aceptado por el sistema, y mientras dure la fase de migración entre sistemas Exchange, se configura el dominio “midominio.com” como Internal Relay. Este cambio también ha de realizarse en el entorno viejo de modo que se genere un flujo de correo interno para los usuarios migrados y los que quedan por migrar.

image

A la vez que se crea un Send Connector adicional para redirigir el correo de los usuarios que no estén migrados al nuevo entorno al entorno antiguo

En Transport Settings dentro de Global Settings establecemos los límites de envío y recepción de tamaños de correos para toda la organización.

image

1.2 Configuración del servidor

La configuración a nivel de servidor es la que viene por defecto en la instalación del producto.

1.3 Cross-Forest connector

El primer paso para crear un Cross-Forest connector con external authentication es el abrir Exchange Management Shell y ejecutar el siguiente cmdlet New-SendConnector, concretamente con la sentencia siguiente:

New-SendConnector -Name «Cross-Forest» -Usage Internal -AddressSpaces midominio.com –SmartHosts ht1.midominio.com, ht2.midominio.com -SmartHostAuthMechanism None -SourceTransportServers cas1.midominio.com, cas2.midominio.com-DNSRoutingEnabled $false

Finalmente, se han de dar los permisos adecuados al nuevo conector “Cross-Forest” ejecutando el archivo .ps1 “Enable-CrossForestConnector” que está dentro de la carpeta de scripts de Exchange 2010, en la ruta donde lo hemos instalado.

image

Este conector también se ha de crear en el entorno viejo de modo que también sea capaz de realizar el relay interno de correos entre ambos sistemas.

Para que cada sistema pueda recibir los correos del sistema contrario, se crearán unos Receive Connectors en los CAS del nuevo entorno y modificaran los del entorno actual para aceptar conexiones entrantes de envíos.

Para crear un Receive Connector, vamos a la parte de la EMC de Server Configuration, Hub Transport y escogemos la opción New-ReceiveConnector de las opciones del menú de la parte derecha.

image

Le damos un nombre significativo, el tipo es Internal y añadimos las IPs de los HT del otro dominio (HT1 y HT2) y de los IronPort

image

Modificamos la Autenticación desmarcando todas las casillas y en los permisos de grupos, marcamos que acepte usuarios de Exchange y usuarios anónimos.

image

Con esto queda configurado el rol de HT en el nuevo entorno pero para que todo funcione bien, se han de repetir los pasos de creación del Cross-Forest Connector, Recive Connector y añadir las IPs de los CAS1 y CAS2 en los servidores que tienen el rol de HT en el entorno viejo, que son HT1 y HT2

New-SendConnector -Name «Cross-Forest» -Usage Internal -AddressSpaces midominio.com –SmartHosts cas1.midominio.com, cas2.midominio.com -SmartHostAuthMechanism None -SourceTransportServers ht1.midominio.com, ht2.midominio.com-DNSRoutingEnabled $false


Próximo paso, crear un DAG con los dos MBX que hemos instalado….

Marc