Hola a todos,

Al igual que algunos de vosotros, se acerca el veranito y estoy planteandome la posiblidad de preparar alguna certificación en el periodo de vacaciones y/o menos carga de trabajo.

Para prepararlo, utilizo mi gran portatil C2D 😉 e intento montar todas las prácticas en él aunque sea a nivel paupérrimo.

Este verano, voy a probar de sacarme el MCSA Windows Server 2012, y digo probar, por que veo que laboralmente, lo voy a tener un poco más liado de la cuenta.

El MCSA se compone de 3 exámenes:

• Exam 410: Installing and Configuring Windows Server 2012
• Exam 411: Administering Windows Server 2012
• Exam 412: Configuring Advanced Windows Server 2012

Y es aconsejable realizarlo por ese orden.

El material de estudio que voy a utilizar, va a ser:

• Visión general de Windows 2012: sus roles, características, con un curso de MVA: http://www.microsoftvirtualacademy.com/training-courses/windows-server-2012-technical-overview
• Examenes:  Desde la comunidad Born To Learn, han preparado una serie de formaciones en diferentes perfiles de tecnología Microsoft (SQL, Windows Server, Virtualización, etc), y voy a escoger la parte de WindowsServer, por lo tanto, voy a tener que tener claro los siguientes conceptos antes de presentarme al examen:
  • Exam 410: Installing and Configuring Windows Server 2012
    
    • Install and Configure Servers
    • Configure Server Roles and Features
    • Configure Hyper-V
    • Deploy and Configure Core Network Services
    • Install and Administer Active Directory
    • Create and Manage Group Policy
  • Exam 411: Administering Windows Server 2012
    • Deploy, Manage, and Maintain Servers
    • Configure File and Print Services
    • Configure Network Services and Access
    • Configure a Network Policy Server Infrastructure
    • Configure and Manage Active Directory
    • Configure and Manage Group Policy
  • Exam 412: Configuring Advanced Windows Server 2012
    • Configure and Manage High Availability
    • Configure File and Storage Solutions
    • Implement Business Continuity and Disaster Recovery
    • Configure Network Services
    • Configure the Active Directory Infrastructure
    • Configure Identity and Access Solutions

Y en cada uno de estos temas, existen link para cada una de las áreas a tocar, desde los requerimientos mínimos para cada uno de las versiones de los servidores, como de las formas de instalación (core, full, core-gui), hasta procedimientos de instalación de los diferentes roles y/o caracteristicas, así como resolución de problemas (que creo que es lo más difícil).

A parte de que existe una promo que finaliza el 30 de Mayo, de un 20% en los exámenes y el Second Shot (Exámen extra en caso de ser suspendido), desde el siguiente enlace: http://www.microsoftvirtualacademy.com/offers/20-percent-off-exam-and-free-second-shot?prid=WWLex_MktgFY14ITOffer_LeX

Hola a todos,

Después de haber probado durante una semana esta solución gratuíta para monitorizar de Microsoft, voy a explicar como podemos reconfigurar nuestro agente o Gateway para que reporte al Cloud de monitorización.

Para esta reconfiguración, la realizaremos desde el editor de registro de Windows, como ya sabéis, pulsando [Windows+R] y escribiendo regedit, podremos acceder al registro (es posible que a causa del UAC, nos pida elevar privilegios de usuario. Lo hacemos).

Empezamos con la reconfiguración del agente:

Navegamos por el árbol de registro hasta: HKEY_LOCAL_MACHINE \Software\Microsoft\SystemCenterAdvisor\Agent

Una vez realizados los cambios, deberemos ir a los servicios y reiniciar el servicio: System Center Management

En caso de querer modificar nuestro servidor Gateway, deberemos ir a la ruta: HKEY_LOCAL_MACHINE \Software\Microsoft\SystemCenterAdvisor\Gateway

Y al igual que con el agente, para aplicar los cambios en el Gateway, será necesario reiniciar el servicio: System Center Advisor Gateway.

Como podemos ver, tenemos un mínimo de configuración para reportar en los horarios en los cuales nuestros usuarios no hacen un uso exaustivo de los servidores.

Hola a todos,

Hoy voy a explicar un poco sobre esta herramienta, que si no eres un técnico muy exigente, te va ha ser de mucha utilidad.

System Center Advisor (forma parte de SCOM), es un agente que se instala en nuestra plataforma Windows Server y es capaz de monitorizar (no a tiempo real), nuestros servidores, el listado de sistemas operativos a monitorizar es el siguiente:

• Windows Server 2012
• Windows Server 2008
• Windows Server 2008 R2
• Hyper-V Server 2012
• Hyper-V Server 2008 R2

Como es de esperar, de plataforma Windows Server 2008 hacia delante.

Y las aplicaciones que por ahora es capaz de monitorizar son las siguientes:

• Windows Server 2008 / 2008 R2 / 2012:
  • Active Directory
  • Hyper-V Host
  • General operating system
• Hyper-V Server 2012
• SQL Server 2008 y posterior
  • SQL Engine
• Microsoft SharePoint Server 2010
• Microsoft Exchange Server 2010
• Microsoft Lync Server 2010
• Microsoft Lync Server 2013
  
• System Center 2012 SP1 – Virtual Machine Manager

Como podemos observar, es posible monitorizar casi toda la plataforma Microsoft desde W2K8 hacia arriba.

Voy ha hacer un inciso respecto a «tecnico no muy exigente», para que no haya malos entendidos 😉 este producto que es gratuito, monitoriza sistemas operativos de Microsoft y aplicaciones del mismo, pero, desde que se instala un agente, no empieza a enviar reportes hasta una vez pasado 24 horas, y otro motivo, es que, sólo guardará los datos recolectados de 5 días, por lo tanto, será tarea nuestra el ir exportando de alguna manera estos datos para tenerlos en caso de necesidad.

Alta del servicio

Para dar de alta el servicio e iniciar el proceso de monitorización, deberemos acceder a https://www.systemcenteradvisor.com y darnos de alta con una cuenta Microsoft Account (@outlook.com, live.com, etc o Office365). Una vez hayamos accedido, nos pedirá algunos datos sobre la cuenta:

Aceptamos el contrato de licencia:

Nos indica que la cuenta ya ha sido activada, y que vamos a proceder a iniciar el despliegue de la solución (en este caso, a descargar los requerimientos de software para poder instalarlos posteriormente)

Nos muestra un ejemplo de despliegue, en el cual, al lado derecho de la imagen, observamos la solución que vamos a instalar. Ya que la solución de la izquierda, requiere de SCOM (System Center Operation Manager) y es un producto del cual no dispongo.

Nos descargamos tanto el SETUP como el CERTIFICADO y lo guardamos en un directorio que podamos acceder desde los servidores a monitorizar.

Nos indican como debemos proceder para la instalación de los agentes:

Nos indican como realizar el mismo procedimiento de descarga de software desde la consola de administración:

 Instalación del agente

El agente necesita como requisito para poder ser instalado en un servidor del Framework 3.5, por lo tanto, en mi caso que el servidor no lo tiene instalado, voy a proceder a la instalación:

Abrimos el ServerManager y accedemos a apartado de Features (Características), y pulsamos en Add Feature (añadir caracteristica)

En el asistente que nos aparece despliego .NET Framework 2.5.1 Features y selecciono .NET Framework 3.5.1

Confirmamos la instalación de características a instalar y esperamos.

Una vez finalizada la instalación de .NET, iniciaremos la instalación del Gateway y del agente:

• Gateway: Será el encargado de recolectar la información de todos los servidores que estén configurados para que le reporten, y será el que tenga acceso a internet.
• Agente: Es la aplicación de monitorización que irá recopilando información sobre el servidor y sus estados.

Ejecutamos el ejutable (AdvisorSetup.exe) y seguimos las indicaciones:

Al seleccionar Gateway, nos muestra una advertencia de que para este servidor será necesario abrir el puerto 80 hacia internet para la comunicación entre el agente y Azure.

A partir de aquí será la instalación de un agente sin gateway

Primera configuración

Indico primera configuración, por que hasta que no haya pasado el periodo de 24h, no podré saber si el agente se puede configurar de alguna otra manera, y que parámetros voy a poder configurar.

Al iniciar la primera configuración del Gateway, tendremos que indicar la ubicación del certificado, que previamente nos hemos bajado.

Indicaremos si el servidor debe de realizar la actualización de parcheado desde Microsoft Update (por defecto, indicaremos que si).

Comprobamos que toda la configuración a aplicar sea correcta.

Esperamos a que se vaya configurando toda la parte de Gateway como de agente que hemos instalado en este equipo

Una vez finalizadas todas las tareas, y al haberle marcado la opción de Microsoft Update, se abrirá esta utilidad y buscará los últimos parches a bajar e instalar.

Ayuda del producto: ayuda System Center Advisor

Hola todos,

Primero de todo, quiero felicitar el año nuevo que hemos inaugurado hacer relativamente pocas horas ;))

El año pasado, para Septiembrese realizó el evento Citrix Geek Speak Local 2013 en Barcelona, y Javier Sánchez (@Ctxdom), me invitó a dar una charla.

Como no sabia de que hablar y el DataStore (es la BBDD de una arquitectura Citrix), es critica, me decidí a explicar como configurarla para que en caso de caída, no se viese afectada.

Podéis ver mas vídeos del evento en el canal de vídeos de CTXDOM y 101Consulting en: http://vimeo.com/ctxdom/videos

Un Saludo

Creación de Clúster W2K0R2 en VMWARE

Hola a todos,

Me han pedido generar un clúster de Windows para implementar un servicio de ficheros para la organización. Se ha decidido crear dicho servicio en la plataforma virtual, gestionada en VMWARE.

Para montar dicho clúster, tenemos que tener en cuenta que se deberá de activar la afinidad de host en VMWARE para que no se pueda mover la VM a otro host en caso de caída, este requerimiento es necesario porque vamos a generar un enlace iSCSI contra el almacenamiento en donde vamos a alojar los ficheros de los usuario.

Creamos los 2 servidores Windows Server 2008 R2 Enterprise de forma estándar (instalación limpia y/o template), en mi caso, van a ser ServerCore, por que no es necesario sobrecargar el servidor con la interface gráfica (GUI).

Desde el servidor NAS deberemos presentar las LUNs que queremos montar en el cluster (QUORUM y DATOS), y seguir el procedimiento desde VI.

Añadimos un nuevo disco

Indicamos que va a ser un disco RAW

Nos indica que tenemos 2 LUNs disponibles, capacidad de 1Gb para el disco de Quorum del Clúster y otra de 300GB para datos.

 Indicamos que queremos realizar el mapeo de la LUN en un disco VMDK, y que se aloje en el mismo Datastore en donde reside la VM.

Indicamos que el modo de compatibilidad va a ser Físico, ya vamos a tratar como si fuese un servidor físico con su controladora física.

 Seleccionamos el drive SCSI, que deberá ser un controlador no utilizado por VMWARE, por ejemplo SCSI (1:0 y 1:1), y deberemos de identificarlos posteriormente, por lo que es recomendable apuntar que LUN va a cada SCSI.

Al final veremos que tenemos 2  nuevos hardware del tipo Mapped Raw LUN. Y que el bus, en cada uno de ellos, será Physical.

En el segundo servidor, deberemos de añadir también los 2 LUN, y configurarlos en el mismo controlador SCSI.

SCSI 1:0 –> Quorum

SCSI 1:1 –> Datos

Indicamos, que vamos a usar un disco existente, ya que seleccionaremos los discos que se han creado cuando hemos generado el mapeo de LUN en el primer servidor.

Seleccionamos cada uno de los discos, que estarán en el Datastore en donde esté alojado el servidor que previamente hemos configurado.

 Seleccionamos el controlador SCSI que pertenece a cada uno de los discos que hemos añadido al mapeo de LUN. Es Necesario e importantísimo realizar la asignación correctamente, por que sino el clúster no funcionará.

 Y también para estos discos, comprobamos que la configuración SCSI está indicada en Physical.

En mi caso, como el clúster está sobre ServerCore, he utilizado un servidor W2K8 para gestionar los 2 servidores y añadir los discos desde la administración de discos.

Hola a todos, Parece que lo haya preparado para este día 31/10 noche de hallowen, pero, me ha pasado aquello que NUNCA debería pasarle a un administrador de sistemas…… 😉

¡¡ No se la password de administrador local de una máquina que no está en dominio!! 😉

Aunque parezca mentira, así a sido, entregué una máquina, y al añadirla a un dominio no gestionado por mí, automáticamente se le realizó un cambio de password por GPO, y al entregarme otra vez la máquina, se le olvidó entregarme el nuevo password de administrador. Busqué por la comunidad TechNet, la solución a mí problema de acceso al server, y en principio la solución era fácil…

1. Entras, en modo a prueba de fallos
2. cambias un fichero
3. lanzas una línea de código para cambiar el password
4. Reinicia el Equipo

Fácil, ¿no? 😉 Pues allá vamos 😉

1. Iniciamos el servidor con el DVD de Windows Server 2008 R2, y seleccionamos reparar equipo.
   
2. Indicamos Idioma del servidor y distribución del teclado.
3. Seleccionamos que queremos utilizar herramientas (cmd) para intentar recuperar el sistema.
   
4. Identificamos cual es nuestra unidad de sistema, Si tenemos problemas utilizamos la utilidad DiskPart para identificarla.
   
5. Navegamos hasta C:\Windows\System32 y comprobamos que en que estado se encuentra Utilman.exe.
   
6. Si es mi caso que no existe, copiamos CMD.exe como Utilman.exe, y reiniciamos el servidor.
7. Dejamos que cargue Windows 2008 R2 desde el disco y en la pantalla de Logon, pulsamos CMD+U (Windows+U).
8. Nos aparece una pantalla CMD y escribimos la siguiente línea:
   net user administrador MiContraseña
9. Reiniciamos el equipo, cargando desde el DVD de instalación y realizamos otra vez la tarea de reparar (los 5 primeros pasos).
10. Como en mi servidor NO existía Utilman.exe, voy a proceder a borrar con la sentencia: del utilman.exe.
11. Reinicio con carga desde el disco duro del equipo y al realizar el logon del usuario administrador indico que la nueva contraseña es: MiContraseña.

Hola a todos,

Esta va a ser una entrada bastante rápida 😉 Muchas veces, nos preguntamos si una aplicación o algún componente será compatible con nuestro sistema operativo, y para poder saberlo, lo único que hacemos es instalar y probar si la aplicación funciona o el hardware es reconocido por el sistema y tiene drivers disponibles.

Microsoft tiene desde hace bastante tiempo una web que nos ayudará a saber la compatiblidad de las aplicaciones o componentes antes de adquirirlos o instalarlos, ya que cada fabricante informa si certifica la utilización de su solución en las plataformas servidor de Microsoft (Windows Server 2012, 2008 R2, 2008, 2003).

URL: http://www.windowsservercatalog.com

Los logos que vamos a poder ver son los siguientes:

Certificado: Se ha validado su correcto funcionamiento con la versión indicada.

Diseñado: Se ha generado pensando en la plataforma en donde se va a implementar.

A los fabricantes les interesa que Microsoft les certifique su solución por que de esta manera les posiciona positivamente delante de sus competidores directos.

Hola a todos,

He tenido que montar un piloto para probar que tal se comporta los servidores SQL en modo espejo y añadiendo un tercer servidor que realice las tereas de testigo, para realizar la alta disponibilidad y de esta manera tener el mínimo tiempo posible el acceso a la BBDD caído.

El piloto se realiza con 2 servidores de producción, y un servidor testigo. En todos los servidores se ha instalado la misma versión de sistema operativo y de MS-SQL Server: Windows Server 2008 R2 y SQL-Server 2008 R2. En el equipo de testigo, se podría haber instalado un SQL-Express 2008, ya que en ningún momento tendrá la instancia de BBDD, y simplemente recoge información de quien tiene el rol activo.

Instalación de MS-SQL

Aunque la instalación de SQL SERVER tiene bastantes opciones en el momento de instalar, deberemos de tener en cuenta varias indicaciones del asistente de instalación para después esté todo operativo correctamente.

Deberemos de instalar .NET FrameWork 3.5.1 e iniciar el setup de instalación, pasando, como se observa en la imágen, todas las operaciones de control con «Passed», y en el caso de tener Warning, intentar solucionarlo.

En caso de tener Failed, no podríamos continuar hasta solucionar el requerimiento de instalación.

Instalamos una instancia estandard de SQL SERVER.

En mi caso, es necesario la instalación de Analysis y Reporting Services. Tendremos que seleccionar las herramientas de administración, para tener acceso a «SQL-SEVER Management Studio».  No olvidar seleccionar SQL Server Replication, ya que será la tecnología que vamos a utilizar para realizar el modo espejo.

He generado una tabla Excel (GruposM) con información de ACLs en un recurso compartido, para realizar las pruebas.

Configuración de modo de espejo con testigo

Lo primero que tenemos que realizar es un backup de la BBDD que queremos tener en alta disponibilidad, para esto, necesitamos comprobar que el modo de copia de seguridad tiene que estar en modo FULL.

Desde el servidor en donde está ubicada la BBDD, y desde SQL SERVER Management Studio, realizaremos la exportación de la BBD y del fichero de log:

backup database GruposM to Disk=»C:\BackupBBDD\GruposM.bak»;
backup Log GruposM to Disk=»C:\BackupBBDD\LogGruposM.bak»;

Copiamos el directorio en el servidor SQL que servirá de espejo (TSQL02), y restauraremos la BBDD y el Log.

restore DataBase GruposM from Disk=»C:\BackupBBDD\GruposM.bak» with NORECOVERY;restore Log GruposM from Disk=»C:\BackupBBDD\LogGruposM.bak» with NORECOVERY;

Veremos que la BBDD se queda en modo Restoring…, nos iremos al TSQL01 e inicimos el proceso de Espejo.

Pulsaremos botón derecho encima de la BBDD que requiera estar en Espejo, y pulsamos en Tasks > Mirror…

Pulsamos en Configuring Security e iniciamos el Wizard de configuración de seguridad.

Como en nuestra solución vamos a incluir un testigo, vamos a indicar que SI lo vamos a utilizar
Indicamos que la configuración se va a guardar tanto en los servidores principales, como en los de Espejo y marcamos la opción de Testigo.

Tenemos que abrir en el Firewall de Windows el puerto 5022 en cada uno de los servidores de alta disponibilidad.

Al pulsar conectar, nos indicará que tenemos que realizar logon con un usuario, cambiaremos e indicaremos el usuario SA con su respectiva contraseña.

Realizamos las mismas acciones en cada uno de los servidores espejos que vamos a utilizar, indicando el nombre del servidor y pulsando en Connect… para realizar el Logon en el SQL-SERVER del servidor.

Para el testigo, realizamos las mismas acciones que con un equipo de espejo. Indicar el nombre del servidor y pulsar Conectar para realizar el logon.

Pulsamos en Finish del wizard que inicie la configuración de Espejo.

Esperamos a que finalic la configuración.

Mientras, podremos ver como la BBDD que hemos seleccionado para que esté en alta disponibilidad, va cambiando el estado en cada uno de los servidores espejo, el proceso es de validación de los ficheros la BBDD.

El estado final será que en Servidor Principal, veremos que la BBDD está en modo (Principal, Synchronized), y los servidores en estado Espejo, estarán en modo (Mirror, Synchronized /Restoring…)

Provando la Alta disponibilidad

Lo primero que deberemos hacer es bajarnos el Cliente Nativo para SQL-Server, en mi caso para SQL-Server 2008, para poder configurar los servidores de espejo que tiene nuestro entorno y no perder conectividad con los datos. En caso de utilizar el driver ODBC de SQL Server del sistema, sólo podremos indicar 1 servidor SQL para realizar la conexión, y en caso de Failover, deberemos configurar el ODBC para que apunte al otro servidor SQL (o crear 2 origenes ODBC).

Indicaremos información descriptiva del origen de datos que vamos a crear, y cual es el servidor principal del entorno.

Indicaremos que nos vamos a conectar con el usuario SA o un usuario con permisos en la BBDD.

Indicamos cual es la BBDD que vamos a tener como predeterminada, y la cual, va estar en alta disponibilidad, e informamos de igual manera del servidor de espejo que tenemos en la plataforma.

Deberemos desmarcar la opción de Adjuntar nombre del archivo de la base de datos.

Pulsamos a finalizar para acabar la configuración del enlace ODBC.

Como vemos, en la imagen, tenemos marcada en color rojo, el origen de datos que vamos a utilizar como alta disponibilidad, mientras que en el registro superior, tendríamos el generado con el driver SQL-Server del sistema, que no nos daría la posibilidad de realizar la acciones de Alta disponibilidad.

Provando la alta disponibilidad

Al abrir unos Access 2007 para probar el acceso a datos de alta disponibilidad y realizar el Failover, deberemos de comprobar, que los datos son correctos (previamente han sido configurados en el ODBC del sistema).

Realizamos una consulta a la BBDD, para comprobar que podemos explotar los datos:

SELECT *
FROM dbo_tabla
Where dbo_tabla.INHERIT=»NO»;

Y a continuación probaremos el Filover y sin cerrar el access , volveremos a lanzar la consulta.

Nos indicará que se ha perdido la conexión a la BBDD. Cerraremos Access, volveremos a abrirlo (para que el driver ODBC sepa que tiene que cambiar de servidor origen) y podremos continuar con la tarea, ya que los datos estaran en linea.

En otras aplicaciones como puede ser SharePoint, es capaz de comprobar si el servidor ha cambiado de estado y el rol de Servidor Principal ha cambiado, sin tener que reiniciar el enlace de datos.

Hola a todos,

Me han pedido que realice unos cambios en cerca de 3000 objetos usuarios de directorio activo, entre los que están:
1- Cambiar el estado del usuario a Deshabilitado
2- Modificar un atributo del usuario para ocultarlo de la Libreta de direcciones de Exchange.

El punto 1, basicamente, lo solucioné con un Script que consultaba los atributos LastLogonTimeStamp y LastLogon, y manualmente se deshabilitaban aquellos que eran usuarios no genéricos, que tienen nomenclatura similar los usuario normales.

Para saber estos usuarios, desde la consola de administración de Directorio Activo, se ha realizado una búsqueda personalizada en la cual se indica que los atributos LastLogonTimeStamp sea vacío (nunca ha realizado logon en el dominio) o sea anterior a una fecha determinada, en nuestro caso 01/01/2012.

(&((objectCategory=person)(objectClass=user)(|(lastLogonTimestamp<=1325376000)(!lastLogonTimestamp=*))))

Para indicar el valor de TimeStamp, he utilizado la calculadora WEB:

• http://www.onlineconversion.com/unix_time.htm
• http://www.pedroventura.com/utilidades/conversor-timestamp-a-fecha
• http://www.unixtimestamp.com/index.php

Una vez que he tenido los usuario en Disable, ha tocado ocultar aquellos usuarios que el departamento de RRHH ha indicado por baja en la empresa.

Para poder realizar las acciones sobre el check a marcar:

Corresponde al atributo del objeto: msExchHideFromAddressLists, que podemos visualizar al abrir el objeto de usuario con la herramienta adsiedit.msc.
Para iniciar las pruebas mediante powershell, probé con visualizar los usuarios que tuviesen el check marcado (true), es decir, que no se ven en la libreta de direcciones o desmarcado (false).

Get-QADUser -Disabled -oa @{‘msExchHideFromAddressLists’=$true}

Para poder modificar tenía 2 formas, una más «elegante que otra», ya que en un Script podía trabajar con Logs de los usuarios modificados.

Sin Logs y a lo loco 😉

Get-QADUser -Disabled | Set-QADUser -oa @{‘msExchHideFromAddressLists’=$true}

Con Logs y más elegante

get-qaduser -searchroot «OU=Disable,DC=domain,DC=local» -IncludedProperties MSExchHideFromAddressLists | where-object {-not $_.MSExchHideFromAddressLists} | set-qaduser -objectAttributes @{MSExchHideFromAddressLists=$true} -Confirm | Tee-Object -FilePath «Ocultos_Exchange.txt»

Pero, como esto hubiese sido muy fácil, este cambio no querían realizarlo de forma masiva sobre toda la OU de DISABLE, e ir haciendo estas modificaciones, previo aviso, otra vez, del departamento de RRHH.

Después de todo esto, y hablando con compañero, me indicaron una herramienta que ha estado toda la vida ahí, y ha sido para mí una gran desconocida 😉

AD MODIFIY: http://admodify.codeplex.com/

Es una herramienta que nos permite, mediante una consulta previa sobre AD, modificar cualquier atributo de manera visual.

Abrimos la herramienta con permisos de modificación en AD, y pulsamos en MODIFY ATTRIBUTES

Seleccionamos el dominio sobre el cual queremos actuar y sobre que equipo con el rol de Directorio Activo, queremos actuar.

En mi caso, no me hará falta realizar una consulta sobre AD, ya que los elementos a modificar los tengo en el OU de Disable\Users. Navegaré hasta la OU y pulsaremos en ADD TO LIST.

Seleccionamos los objetos que queremos modificar.

Y ahora, y de forma visual, podemos modificar el atributo que queremos sin ningún tipo de problema 😉

Un Saludo,

Manu

• Hola a todos,

He tenido que recuperar un System Center Configuration Manager 2007 R2, con error de hardware e irrecuperable. Se ha tenido que proceder a instalar nuevamente una plataforma de similares característica al servidor origen:

• Windows Server 2008 R2 Enterprise
• MS-SQL 2005 Standard x32
• 2 x vCPU
• 6Gb vRAM
• 300Gb vHDD

Para poder recuperar la plataforma de SCCM, lo más similar posible a la que teníamos en producción, es necesario el haber realizado el SiteBackup y tener una copia del FileSystem del servidor.

Una vez instalado el sistema operativo y SQL Server, procederemos a iniciar el restore de SCCM.

Es recomendable el recuperar de la copia de seguridad los directorios:

• SMSData
• SMSPKGC$
• SMSPKGSIG
• SMSSIG$

Y los directorios, si es posible, de donde guardemos los binarios de los paquetes de instalación de las aplicaciones paquetizadas (por si acaso).

Copiaremos los ficheros de la BBDD de SCCM al directorio de SQL-Server

• copy [UNIDAD]:\SiteBackup\SMS_Site\SiteDBServer\ *.mdf [UNIDAD]:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\
• copy [UNIDAD]:\SiteBackup\SMS_Site\SiteDBServer\ *.ldf [UNIDAD]:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\

Y una vez copiado, realizar el attach de la BBDD.

Navegamos hasta el directorio «\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\» y seleccionamos el fichero que previamente hemos copiado: SMS_Site.mdf
.

Ahora, tendremos que abrir el desplegable de la BBDD e ir hacia las opciones de seguridad para visualizar los usuarios que existían anteriormente, ya que tendremos que utilizar uno de estos (y que tenga permisos de dbowner), para realizar el posterior proceso de Site Recovery Wizard.

Tendremos que añadir un usuario de la BBDD con permisos de DBOWNER, a la seguridad de SQL-Server.

Y posteriormente asegurarnos de que también está en la seguridad de la BBDD

Para hacer el SiteRecovery, tendremos que tener en cuenta de que las BBDD de SCCM ya la tenemos en la ubicación correcta, por lo tanto, deberemos de marchar un «check» para que no vuelva a realizar el Attach de la BBDD.

Al marcar la opción vemos que no es requerido volver a copiar y presentar la BBDD en SQL-SERVER, por lo tanto, nos indica que la acción es Not Requiered.

Si se gerenase algún tipo de error, o quisieramos ver el log de las acciones que se van realizado, deberemos ir a: [UNIDAD]:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\AdminUILog y abrir el fichero: RepairWizard.log.

En la selección de los paquetes, es recomendable el que compruebe la accesibilidad de cada uno de ellos, es un proceso que no tarda demasiado.

Reiniciaremos el servidor y abriremos la consola de gestión de SCCM.
Ahora tocará la parte más tediosa, ya que el servidor SCCM deberá de comprobar a todos los agentes que tiene informados, por lo que este proceso, consumirá bastantes recursos del servidor durante bastante tiempo. Así que comprobamos de que en la consola tenemos informados collections que tengamos creadas, advertisements y lo dejaremos para que realice las tareas en Background que hagan falta.