eManu

Para implementar Windows Intune, podemos realizar varias configuraciones:

• Cloud
• Híbrida (cloud y local)
• Asistida por SSCM

Previo a que arquitectura se puede adecuar más a nuestra organización o solución Intune, deberemos de evaluar los requisitos que ya indiqué en el post anterior, de los equipos a administrar.

Para la opción de MDM, Windows Intune realizará un check del terminal previo al proceso de instalación, por lo que el dispositivo no tendría que tener ningún tipo de Rootkit tipo Jailbreak (IOS).

Instalación del agente

La instalación en el puesto cliente se puede realizar de varias maneras, y deberemos realizar la instalación según el entorno en donde se esté ejecutando el instalador.

Cuando realizamos la inscripción de forma automática, tenemos que dejar en el mismo directorio el fichero de instalación: Windows_Intune_Setup.exe como el certificado de seguridad WindowsIntune.ACCOUNTCERT.

Si utilizamos una distribución basada en Directorio Activo, y tenemos la posibilidad de tener un servidor de directorio en las ubicaciones remotas (AD o RODC), deberíamos comprobar que tenemos tanto el Script de despliegue, como el ejecutable y certificado para no generar más ancho de banda que el necesario.

Si utilizamos una distribución basada en SCCM, tenemos que tener en cuenta, si es posible y así lo tenemos indicado en la infraestructura a desplegar, de que antes de realizar el despliegue del agente, tener el paquete en todos los DistributionPoints de SCCM, para minimizar lo máximo posible el tráfico de WAN/LAN.

Para desplegar el agente mediante imágenes de sistema operativo, se realizará el mismo procedimiento que para SCCM, pero el paquete de SCCM, indicarlo lo antes posible de cualquier otra instalación para que vaya informando del software instalado en el equipo.

El agente se instalará en unos 30 minutos, aunque la totalidad de la instalación podría tardar (según la línea de datos), hasta un par de horas. Esto es debido, a que es necesario la descarga de los diferentes componentes en los que se apoya Windows Intune y la actualización de los mismos.

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,

OS paso un link en donde vamos a poder descargar unos posters con la arquitectura de Hyper-V para Windows Server 2012 R2.

Se descarga un fichero con estos PDFs:

• 2a Generación de VM.
• Hyper-V Failover Clustering
• Hyper-V Storage
• Hyper-V virtual disk sharing
• Live Migration

URL: http://www.microsoft.com/en-us/download/details.aspx?id=40732

Espero que OS sea de utilidad!!!

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,

Recientemente he tenido que reinstalar mi Windows8Pro por un casque de HDD, como fuí uno de los que compró licencia de actualización de sistema, debería de instalar una versión anterior a Windows 8 (> WinXP SP3), para que la instalación de reconozca mi numero de serie correctamente.

Como se puede entender, esto es un poco cansino, aunque Windows7 se instale en 10 minutos 😉 , por lo que he estado buscando y he encontrado la forma para poder realizar todo el proceso de instalación de Windows 8 desde instalación limpia y poder utilizar mi numero de serie.

1. Ejecutamos REGEDIT.EXE con privilegios de administrador
   1. Abriendo un CMD como administrador y llamando a regedit
   2. en Escritorio clásico haciendo la combinación CTRL+R y escribiendo REGEDIT
2. Navegamos hasta la rama de registro: HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Setup/OOBE/
3. Cambiamos el valor de la variable: MediaBootInstall de 1 a 0
4. ejecutamos CMD como administrador y lanzamos la siguiente sentencia: slmgr /rearm
5. Reiniciamos el equipo
6. lanzamos la activación de la licencia.

Hola a todos,

Voy a poner una pequeña entrada para un curso gratuito que podéis realizar online, y que se realiza desde Microsoft México, en donde se trataran temas de Windows Server, System Center y Windows Azure.

Está dirigido para profesiones de infraestructura e interesa, los temas a tratar son los siguientes:

• Construcción y administración de la Nube en las empresas
• Tendencias y retos en las áreas de TI
• Infraestructura del centro de datos
• Virtualizando tu infraestructura
• Introducción al cómputo en la nube
• Cloud OS
• Administrando la Nube
  • Administración de la virtualización
  • Monitoreo
  • Servicio y automatización
  • Aplicaciones
• Escenarios en Azure

Si estas interesado en realizarlo tienes que dirigirte a: http://www.microsoft.com/mexico/shareit/it-diploma.aspx

Un Saludo!

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.