eManu

Consideraciones en el equipo cliente

Antes de iniciar una implantación de Intune tenemos que tener en cuenta varios aspectos y saber cómo vamos a distribuir los agentes Intune una vez que tenemos identificados los equipos que van a ser administrados de la nube.

Existen restricciones tanto a nivel de Software como de Hardware, por lo tanto, lo primero que vamos a tener que hacer es realizar un estudio de los equipos que queremos administrar.

A nivel de Software, sólo podemos instalar el agente en plataformas Microsoft y cómo mínimo el sistema operativo indicado en la siguiente tabla:

Para las opciones MDM, y como en otros sistemas de Administración de equipos móviles, existen restricciones en caso de despliegue de software en los dispositivos, como por ejemplo, en IOS es necesario que la organización tenga una cuenta de desarrollo de AppleStore, ya que sólo se instalará el fichero .IPA si este está firmado por Apple.

A nivel de Hardware deberemos de tener un equipo con las siguientes características mínimas:

Otros aspectos importantes a tener en cuenta:

• El equipo debe de contar con Windows Installer 3.1
• En el momento de la instalación, el usuario que instala el agente de Windows Intune, debe de tener permisos de administrador sobre el equipo.

Consideraciones de red

Para poder administrar los equipos que están detrás de un proxy y/o firewall, será necesario el tener abiertos algunos puertos (80 y 443) hacia los siguientes destinos:

Los agentes van a realizar un uso según los componentes que habilitemos en cada uno de ellos, pero, las estimaciones de tráfico por cada agente son:

De todas maneras, aunque parezca que va a producirse bastante tráfico de red, para los agentes que ejecuten Windows 7 y Windows 8, y no tengan aplicada una GPO que deshabilite BranchCache, estos podrán realizar las acciones de DistributionPoint una vez que se hayan descargado los componentes a actualizar, de esta manera, el consumo de ancho de banda se minizará.

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,

En esta última entrada en referencia a los Roles de administración, voy a dejar una tabla-resumen, en donde indico que se puede hacer con cada uno de los Rol en cuestión.

Hola,

Volvemos a la carga, con el Rol, que posiblemente más uso se le tenga que dar en la organización. Con este Rol podremos realizar la creación y modificación de usuarios de Windows Intune, con la única limitación, de que estos usuarios no podrán ser ningún Rol de Administración, para crear un usuario con dicho Rol, deberá generarse con el Administrador Global de Windows Intune.

Como vemos, si con este Rol vamos generando un usuario de Windows Intune, la misma interface nos muestra en gris la configuraciones no podemos realizar, como es la asignación de un rol de administración.

Como he comentado anteriormente, con el Rol de Administración de Usuario, es posible restrablecer las contraseñas de usuarios de Intune, pero no las de los administradores, excepto la cuenta de Administración de Contraseñas, que con este Rol si que es posible cambiarla.

Como podemos ver, la contraseña se puede restrablecer, y se envía un correo a la cuenta indicada, informando la la contraseña en texto plato.

Un Saludo!