Hola

Nos han mandado un equipo nuevo hacer pruebas con Longhorn y demás betas y andamos mirando la mejor manera de acoplar el resto de ferretería que tenemos desperdigada por ahí. Las instalaciones las solemos hacer con un disco de 2.5" externo con interfaz USB, y las máquinas virtuales las solemos almacenar también en este tipo de dispositivos, bien con HDs de 2.5" o de 3.5", pero en todos los casos son IDE. Las máquinas nuevas vienen ya todas con SATA, sean portátiles o sobremesas, y tenemos también algunas controladoras Ultra-2 SCSI con sus correspondientes discos de poca capacidad, pero de los de 10000 RPMs. A la hora de ponerlos todos juntos a funcionar, y teniendo en cuenta el rendimiento, hay que considerar, entre otras cosas, cual es el ancho de banda que nos da el interfaz (USB 2.0, IDE/ATA y SCSI), la STR (Sustained Transfer Rate) del disco y la configuración de los volúmenes (RAID, etc.). Comparto con vosotros un par de enlaces interesantes sobre estas cosas.

• Una tabla que llevaba tiempo buscando, y que resulta que estaba en la Wilipedia. La comparativa de anchos de banda que nos dan los diferentes interfaces de almacenamiento y los buses externos (donde salta a la vista por qué es tan aburrido copiar datos a un dispositivo externo usando un USB 1.0 o 1.1)
• El artículo de Wikipedia dedicado a los Discos Duros donde da unas tasas de transferencia media de 80 MB/s para los discos normales de 7200-10000 RPMs y de 110 MB/s para los discos más rápidos de 15000 RPMs. Lógicamente cada dispositivo tiene sus propias cifras de rendimiento, y este es un buen sitio para ir a bucear en su búsqueda: http://www.storagereview.com/comparison.html
• Una guía de la PC Guide donde se describen en particular y de manera bastante exhaustiva los intríngulis de los discos duros: http://www.pcguide.com/ref/hdd/index.htm . Sobre este tema en particular es interesante leerse la parte de rendimiento, donde describe los factores externos e internos que afectan al mismo. Hay una parte dedicada a los sistemas en RAID

Tres preguntas de examen (¿habrá premio?):

1. En un equipo con discos ATA, ¿cómo ira un SO que hayamos arrancado de un disco externo USB 2.0 en comparación con el del propio HD interno?. ¿Y si el disco del portátil es SATA?
2. Pongamos que tenemos un equipo con un disco SATA donde está corriendo el SO. Queremos montar una máquina virtual en ese equipo. ¿Dónde irá mejor? ¿En el HD SATA o en un disco USB 2.0 externo?
3. Por cuestiones de rendimiento, ¿me merece la pena montar la Ultra-2 SCSI (de un solo canal) con los discos de 10000 RPMs y usarlos en lugar de los discos SATA por ejemplo para correr el SO?

Todas estas preguntas me las hago porque ya no tenemos los blades esos que nos prestaron para el Techday L y porque, en cualquier caso, los portátiles son más fáciles de transportar.

Saludos

Hola de nuevo

Francamente, la paciencia de Dani para recopilar los enlaces directos de descarga de la Beta 3 de Windows Server "Longhorn" es encomiable. Yo sin embargo os recomiendo seguir el proceso que parte desde este enlace, ya que así obtienes también el Product Key necesario para activar la instalación y ahorrarte que falle justo en el momento más incómodo:

http://www.microsoft.com/technet/prodtechnol/beta/lhs/default.mspx

Pero esto va de cotilleos. El otro día publicaba aquí unas líneas acerca de la jerga de las Betas y describía por encima el proceso que llevan los equipos de desarrollo a la hora de hacer un producto de este tamaño. Paralelamente Jose recibía por correo una pregunta curiosa. ¿Cuánto tarda en compilarse una de estas "builds" de Windows? Así es que buscamos internamente alguien que pudiera contestarnos, y un chavalote muy amable llamado Ken, nos contestó como no podía ser de otra manera y sin ser del noroeste de la península. Depende. Menos mal que matizó.

Depende lógicamente del equipo en el que lances la compilación, y de que estés compilando exactamente. Una cosa es compilar todos y cada uno de los componentes para obtener los correspondientes binarios, y otro proceso que se lleva a cabo a continuación es ponerlos todos juntos para construir la "build" propiamente dicha. Además, si esa compilación en particular va a convertirse en una Beta, Release Candidate, CTP o incluso RTM para distribuir al público, hay que llevar a cabo procesos de firmado digital de los binarios y algunas comprobaciones posteriores. Adicionalmente, pueden quererse también construir los paquetes de idioma, versiones internacionales, con Service Pack integrados, etc. La segunda variable es el equipo o equipos en que se lleve a cabo todo esto. En las máquinas de 8 procesadores de 2 cores y 64 GB de RAM la compilación se hace en dos horas y media y el resto del proceso dura otras cuatro. En las máquinas con 4 procesadores de 2 cores y 32 GB de RAM lleva unas 3 horas y media la compilación y hasta 6 el resto de los procesos. En los equipos más normales de un procesador dual core, todo el proceso entero puede durar entre uno y dos días. Por tanto, en el mejor de los casos, te haces un Windows a partir de unos millones de líneas de código en unas seis horas de nada.

Saludos

Todo lo que hay que tener en cuenta, en un solo Whitepaper:

http://www.microsoft.com/downloads/details.aspx?FamilyId=64DB845D-F7A3-4209-8ED2-E261A117FC6B&displaylang=en

Ventajas y desventajas de virtualizar Domain Controllers, escenarios, recomendaciones de instalación para rendimiento, seguridad, almacenamiento y buen funcionamiento, y, sobre todo, especial cuidado a las operaciones.

Inocente pregunta que me transmite Adal, y que en el fondo no resulta tan sencilla de contestar. Veamos

La Virtualización Asistida por Hardware, como su propio nombre indica, son extensiones introducidas en la arquitectura del procesador x86 para facilitar las tareas de virtualización al software corriendo sobre el sistema. Si cuatro son los niveles de privilegio o "anillos" de ejecución en esta arquitectura, desde el 0 o de mayor privilegio, que se destina a las operaciones del kernel de SO, al 3, con privilegios menores que es el utilizado por los procesos de usuario, en esta nueva arquitectura se introduce un anillo interior o ring -1 que será el que un hypervisor o Virtual Machine Monitor usará para aislar todas las capas superiores de software de las operaciones de virtualización. Hay un montón de información de estas cosas por ahí, pero J.L. Medina lo cuenta y comenta aquí.

Como de costumbre, los dos principales fabricantes de procesadores llegan a lo mismo usando diferentes tecnologías, con similitudes pero incompatibles entre sí. Intel, con su Intel Virtualization Technology (o Intel-VT), y AMD con su AMD Virtualization (o AMD-V o también AMD "Pacífica"). Para los muy muy frikis, aquí tenéis lectura profunda:

• Intel-VT: ftp://download.intel.com/technology/itj/2006/v10i3/v10-i3-art01.pdf
• AMD-V: http://developer.amd.com/article_print.jsp?id=14 y http://developer.amd.com/article_print.jsp?id=15

Al igual que sucede con las extensiones de 64-bit (EM64T para Intel y AMD64 para AMD), casi la totalidad de los procesadores de gama media-alta puestos en el mercado en el último año soportan la virtualización asistida por hardware. Pero, ¿cómo estar seguros? He aquí algunos recursos:

• CPU-Z: Antes de nada, una pequeña herramienta freeware que da un buen montón de información sobre la placa, chipset, procesadores y demás ferretería (si se quiere más, mucho más, Sandra es una buena elección. Supongo que todo el mundo tendrás su favorita. Si es así, comparte la información por favor). Esto nos vale para poder empezar a tirar del hilo con algo más de criterio y sin bucear en la BIOS más allá de lo necesario.
• La Intel Processor Spec Finder: En esta herramienta online de Intel, elegimos primeramente la familia de procesadores que nos interese, y posteriormente en Supported Features seleccionamos "Intel Virtualization Technology" (no está de más seleccionar también EM64T)
• Para AMD-V no encuentro una herramienta similar a la anterior. Esta tecnología se incluye en sus procesadores AMD Athlon 64™, Turion X2 64 y AMD Opteron™. Más información en http://www.amdcompare.com/us-en
• Una lista de procesadores recopilada por XenSource: http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors

Además de todo esto, no basta con tener un procesador o procesadores compatibles. La BIOS del equipo debe soportarla, lo que agrega otra variable a la ecuación y nos obliga a visitar la página de descargas correspondiente del fabricante de nuestro hardware. En uno de los portátiles que suelo utilizar, el procesador aparece como soportado en las listas anteriores, pero no me ha aparecido la opción en la BIOS para habilitar/deshabilitar la virtualización hasta que la he actualizado a la última versión del fabricante.

Saludos

Me preguntan a menudo acerca de cómo se puede migrar desde Exchange 2000/2003 a Exchange Server 2007. Lo cierto es que es una pregunta complicada, ya que depende mucho de dónde se parta y a qué se quiera llegar. Algunas consideraciones previas:

• Exchange Server 2007 no se puede instalar en los mismos servidores que Exchange Server 2003. Es decir, no hay una opción de la instalación que sea directamente una actualización. Una de las razones es que Exchange 2007 es un producto de 64-bit (x64) y no hay una versión correspondiente de Exchange 2003.
• No podemos pasar de Exchange 5.5 a Exchange 2007. Hay que pasar forzosamente por Exchange 2000 o 2003.

Así es que resumiendo (el artículo completo está aquí), tenemos dos opciones:

1. Migrar, es decir, crear una nueva organización y posteriormente mover la información que nos interese, principalmente los buzones.
2. "Transicionar", lo que supone integrar uno o varios servidores de buzones en la organización existente, mover los datos de los usuarios e ir retirando los servidores Exchange 2000/2003 paulatinamente.

La tabla de la derecha resume bien los puntos anteriores.

Realmente lo más complicado es el segundo escenario. Hacer coexistir Exchange 2007 con los servidores 2000/2003 de una organización ya existente. La instalación de Exchange 2007 nos extenderá el esquema del Directorio Activo, y durante la instalación en la organización ya existente nos solicitará un bridgehead de un Routing Group existente para montar un par de conectores con dicho grupo. Esto es así debido a que la arquitectura de enrutado de Exchange 2007 cambia con respecto a la de 2003. Toda la documentación sobre cómo hacer todo esto está en este enlace.

Hay dos puntos clave en la transición. El primero es el movimiento de los buzones. En un entorno de forest único se puede hacer tanto mediante la interfaz gráfica como usando un cmdlet de prowershell (move-mailbox). En un entorno multi-forest resulta algo más trabajoso, pro en cualquier caso podéis consultar ambos casos en este enlace. El segundo llegará a la hora de eliminar los Exchange 2000/2003 existentes, para lo cual podemos usar las guías para desinstalar servidores de Exchange 2003 y servidores del Exchange 2000, aunque es el paso más importante será el último de ellos, ya que hay que preocuparse por las réplicas de las carpetas públicas, la generación de la Libreta de Direcciones Offline, eliminar conectores, etc.

Sin embargo, como decía al principio, cuando estamos en estas tesituras es un buen momento para pararse a pensar en el tipo de organización que necesitamos. Desde la más sencilla, que sería un servidor único, a la más compleja con configuraciones multi-dominio, multi-sites, e incluso cross-forest. Estos son buenos enlaces para ayudarnos a decidir qué tipo de organización necesitamos. Como de costumbre, la recomendación es elegir el modelo más simple posible:

• Organización Simple/Estándar: Un único servidor con todos los roles, o varios servidores con los roles distribuidos y uno dedicado para servidor de perímetro:
  • Planning for a Simple Exchange Organization.
  • Planning for a Standard Exchange Organization.
• Organización Grande: Es la organización más compleja posible en un único forest de Directorio Activo (con su jerarquía de dominios en diferentes Sites):
  • Planning for a Large Exchange Organization.
• Organización Compleja: Múltiples forests de Directorio Activo usando tecnologías de sincronización
  • Planning for a Complex Exchange Organization.

Por supuesto, toda la información sobre Exchange 2007 está online en su TechCenter

Saludos

Hola

Hoy se puede descargar ya la Beta 2 de System Center Virtual Machine Manager (SCVMM). En la sesión de Virtualización que hicimos en el Windows Server TechDay realicé una pequeña demo con la Beta1. Dicha versión tenía restricciones muy fuertes sobre el sistema, ya que no se podía instalar en un DC ni en sistemas de 64-bit. Esto ya está resuelto, el módulo de migración de máquina física a virtual ya está incluido y se le ha lavado la cara a la interfaz gráfica para que se parezca a otros productos de la línea de gestión System Center.

Así es que en la Beta 2 de SCVMM tenemos:

• Soporte a x64
• Posibilidad de instalación remota de los componentes
• Migración P2P basada en un sencillo asistente (solo Windows 2000 SP4 y Windows 2003 SP1, por ahora)
• Migración V2V para pasar máquinas virtuales de VMWare a Virtual Server
• Nueva consola de Powershell para poder hacer operaciones con las máquinas virtuales por línea de comandos
• Posibilidad de obtener y gestionar snapshots de Máquinas Virtuales
• Migración de Máquinas Virtuales en entornos de almacenamiento compartido SAN o iSCSI
• Librería donde almacenar Máquinas Virtuales, plantillas, perfiles de harsware, ISOs, VHDs, de modo que la creación y aprovisionamiento de máquinas virtuales viene a ser "pinta y colorea"
• Servicio web de autoservicio

Para descargarla, hay que ir a http://connect.microsoft.com, ir a "Conexiones Disponibles" y apuntarse a System Center Virtual Machine Manager (el enlace directo es https://connect.microsoft.com/vmm).

Lógicamente será parte estrella de la demo que haremos en la Webcast de Migración de máquinas físicas a virtuales que haremos el 29 de Mayo (http://www.microsoft.com/spain/technet/jornadas/default.mspx)

Saludos

Se puede conseguir a través de Microsoft Connect:

https://connect.microsoft.com/Downloads/Downloads.aspx?SiteID=151&wa=wsignin1.0

Recuerdo las novedades:

• Soporte a Virtualización Asistida por Hardware (Intel-VT y AMD-V)
• Soporta más de 64 VM en hosts x64
• Comando VHDMount para manipulación offline de los ficheros .vhd
• Compatible con la Beta 2 de System Center Virtual Machine Manager
• Interoperabilidad con Volume Shadow Copy Service.
• Soporte a guest adicionales (Vista, Longhorn, 2003 SP2…)
• Publicación del servicio en utilizando los Active Directory Service Connection Points
• Whitepaper de Host Clustering incluido en el paquete
• Parche para el Virtual SCSI en maquinas virtuales Linux
• Discos virtuales de hasta 127
• VMRC ActiveX control actualizado
• La propiedad IVMGuestOS::Get_OSName ofrece más información acerca del sistema operativo de la VM

La comparativa con Virtual Server 2005 R2 está en este post.

Recordaros que si vais a hacer algún piloto/proyecto sobre virtualización usando esta nueva versión de Virtual Server o en el futuro con Windows Server Virtualization de Longhorn, os podemos dar algo de apoyo (suscripción gratuita a TechNet, incidentes de soporte gratis, información y eventos personalizados, etc.). Si estáis interesados, basta con que me enviéis un correo.

Saludos

Esa ha sido la cantidad recaudada a base de donar un dólar por cada búsqueda hecha en Windows Live Search, que anunciamos por aquí cuando se lanzó a mediados de Enero. Ya comentamos que España iba en cabeza a nivel mundial en recaudación, y finalmente hemos sido los segundos en recaudación por detrás solamente de Estados Unidos.

Parece que el dinero recaudado se destinará a los programas que UNHCR lleva a cabo en Liberia

Gracias a todos los que habéis participado

Hola

Trataremos estos temas en la Webcast de este jueves sobre cómo virtualizar servidores con roles de infraestructura, en la que os podéis registrar gratuitamente en el enlace correspondiente de nuestra página de Eventos y Webcasts. Hay cambio de ponente y esta vez me toca hablar a mí.

Mientras, he recolectado algunas recetas dispersas allá y acá para mejorar el rendimiento de las máquinas virtuales bajo Virtual Server, y esta es la lista de recomendaciones:

Configuración del Host:

• Por supuesto, la mayor cantidad de memoria y mejores procesadores multi-core que podamos permitirnos. Es conveniente reservar 512 MB de RAM para el host
• Evitar otros servicios/aplicaciones corriendo en el host
• Excluir las rutas de las máquinas virtuales de los paths de monitorización de los antivirus. También es conveniente excluir las extensiones asociadas: .vhd .vud .vsv .vfd .vmc
• No utilizar el modificador /3GB en el boot.ini para dar más espacio de direccionamiento virtual a los procesos del usuario a costa del kernel. Los entornos virtualizados hacen uso intensivo de éste último.
• En las opciones de rendimiento, es preferible tener los recursos del procesador configurados para mejor rendimiento de los servicios en segundo plano y la configuración de memoria optimizada para System Cache.
• Siempre que sea posible, usar varias tarjetas de red Gigabit. Dedicar una NIC al Host y repartir las demás entre las máquinas virtuales según su demanda de ancho de red.
• Configuración del sistema de almacenamiento: Definitivamente este es quizás uno de los puntos definitivos ya que las operaciones de E/S se multiplican a medida que el número de máquinas virtuales concurrentes aumenta. Por eso es importante:
  • Los discos, cuanto más rápidos mejor.
  • Usar diferentes discos para el Sistema Operativo del Host que para las máquinas virtuales
  • Si es posible, utilizar diferentes controladoras.
  • Dedicar un disco a cada máquina virtual. O mejor aún, dedicar a cada una de las máquinas virtuales sus propios volúmenes que comprendan varios discos (RAID 0, o RAID 0+1 si queremos tolerancia a fallos). Y si es posible en SAN, mejor aún.
  • Utilizar volúmenes NTFS con la compresión de datos habilitada. Es más óptimo escribir en disco los datos ya comprimidos, y además ahorraremos un buen porcentaje del tamaño del .vhd
  • Cuidado con los hosts que sean además Controladores de Dominio. El disco que contenga la partición donde se almacena la base de datos del Directorio Activo tendrá la cache de disco deshabilitada. No será buena idea poner un .vhd ahí.

Configuración de las Máquinas Virtuales:

• Asegurarse de tener instaladas la últimas VM Additions en todas las máquinas virtuales del host.
• Tener las máquinas conectadas a la red, aunque sea la red interna de Virtual Server, que solo ofrece conectividad local entre las máquinas conectadas a ella
• Utilizar RDP para conectarse a las máquinas virtuales en lugar de VRMC. Con ello podremos:
  • Cortar y pegar contenido de nuestro escritorio al de la VM.
  • Usar nuestras unidades locales, incluso las USB.
  • Utilizar y la impresora local.
• Usar discos diferenciales para máquinas virtuales muy similares entre sí (esto más por ahorro de espacio que por rendimiento).
• Darle a la máquina virtual suficiente memoria RAM y configurar adecuadamente el fichero de paginación. Así evitaremos paginación en la VM que se pueda traducir en E/S para el host.
• Configuración de los discos virtuales: Nuevamente un punto con especial importancia
  • Utilizar discos virtuales SCSI en lugar de IDE.
  • Utilizar discos de tamaño fijo. Ofrecen mejor rendimiento que los dinámicos.
  • Realizar mantenimiento periódico de los ficheros .vhd:
    • Desfragmentar dentro de la propia VM.
    • Usar el Precompactor.iso
    • Compactar el .vhd

Todo esto esta sacado principalmente de aquí y de aquí. Espero que os sirva, y si alguien tiene algún truco más, para eso están los comentarios.

Saludos

Tino me refiere a un problema existente a la hora de pinchar ciertos dispositivos USB en Windows Vista. El sistema los reconoce como un "USB MASS STORAGE", pero dice no disponer de los drivers para el mismo. La solución que el ha encontrado consiste en forzar que los divers se busquen en la carpeta %systemroot%\system32\driverstore, con lo que la instalación del dispositivo termina correctamente.

Pues bien, buscando buscando resulta que es un problema reportado, que afecta a los dispositivos que requieren del driver Mf.sys (Multifuction Enumerator) para funcionar, ya que este no se extrae por defecto durante la instalación. Este fichero se encuentra en una carpeta que empieza por mf.inf_ y que se cuelga de %systemroot%\system32\driverstore\FileRepository, razón por lo que la solución mencionada funciona estupendamente.

Basta con copiarlo a la carpeta %systemroot%\system32\drivers para que el problema desaparezca. Todo esto esta en su correspondiente KB aqui.

Gracias Tino

Daniel Matey se emocionaba la semana pasada con la disponibilidad de la "Escrow" de la Beta 3 de Windows Server Longhorn. Pero esto, en el fondo, no es la Beta 3 sino un paso previo. Así es que vamos a ver si podemos aclarar un poco qué es éste jaleo de Betas, CTPs, RCs, con sus escrows, Lockdowns, builds, etc que muchas veces se lee por ahí.

Dentro de una metodología de gestión de proyectos general, los equipos de desarrollo de Windows pasan por cinco fases bien definidas y diferenciadas:

• Análisis de Requerimientos
• Diseño
• Implementación
• Verificación
• Puesta en el mercado

Durante las dos primeras fases se decide que características tendrá el producto, se trabaja en documentos detallados con las especificaciones que han de cumplir cada una de ellas y se crea una agenda en la que se van definiendo diferentes objetivos o "milestones", que determinan el orden en el que los equipos de desarrollo las irán implementando. Obviamente esto es bastante complejo, ya que hay funcionalidades de los productos que dependen unas de otras y hay que definir las estructuras, funciones e interfaces que habrá que codificar para cumplir con todos los requerimientos.

La fase de implementación se centra en la programación, documentación y pruebas de dichas características. Los diferentes equipos de desarrollo pueden estar al cargo de una o varias de ellas, y equipos independientes se encargan de pasar las baterías de pruebas predefinidas (seguridad, funcionalidad, stress, etc.) y de reportar los "bugs" que encuentren tras analizar los resultados de las mismas. Esta fase termina cuando los equipos han finalizado de implementar las características básicas del producto y estas han sido probadas sin encontrarse problemas que pudieran impedir su uso. Es durante esta fase, previa a las Betas, en la que se suele involucrar a clientes en los programas TAP para ir comprobando el funcionamiento del producto en escenarios reales.

Cada noche de los días de diario se construye una "build" completa del producto que comprende las diferentes plataformas, e incluso los diferentes SKUs o versiones, y que recoge el trabajo de todos los equipos hasta ese momento. Probarlas es un ejercicio divertido a la par que arriesgado, sobre todo si estas fuera de los equipos de desarrollo y testeo y de sus canales de información. Puede suceder que lo que funcionaba ayer no funcione hoy en absoluto y viceversa. Preparando el Techday nos sucedió que ningún Terminal Server abría el puerto 3389 independientemente del equipo. Sin embargo la build del día siguiente funcionaba en ese sentido estupendamente y fue la que utilizamos para jugárnosla en directo con nuestras demos extremas. No obstante los equipos de testeo "marcan" algunas compilaciones específicas que cumplen con ciertos patrones de calidad predefinidos de manera que puedan usarse como referencia para pruebas o incluso despliegues internos (que llamamos "dogfooding").

En la fase de verificación comienza cuando todas las características, o un alto porcentaje de ellas, están implementadas en la "build" principal, aunque lógicamente los desarrolladores siguen trabajando. En esta fase se trata de recopilar los resultados de las pruebas que los "beta testers" realizan independientemente, reportar los bugs y dedicarse a arreglarlos. El número de Betas, si estarán soportadas o no, su difusión, etc., dependen de cada proyecto. Una vez absolutamente todas las características están completas, llegan las Release Candidates (RCs). Son builds que se consideran lo suficientemente buenas como para convertirse en producto final. Una vez el producto entra en esta fase, solamente se arreglarse los fallos que se encuentren en dichas builds. En los casos que yo recuerdo, ha habido tres Betas y dos Release Candidates de las versiones de Windows. Sin embargo es frecuente también que se liberen también compilaciones mensuales o Community Technical Previews (CTPs) con el propósito de que la comunidad de profesionales pueda evaluar los progresos y usarlas para sus propias pruebas.

Lógicamente, el proceso anterior es lo suficientemente complejo como para que haya una única línea de "builds". En las semanas previas a la liberación de una compilación importante (una Beta, RC, CTP o una versión que se vaya a distribuir masivamente, en un evento, por ejemplo), generalmente se produce una ramificación sobre la que se hacen dos cosas. Primeramente todos los equipos ponen encima de la mesa los bugs que manejan en ese momento para asegurarse de que todos están utilizando criterios similares (curiosamente a estas reuniones las llaman "War" y deben ser francamente curiosas de ver) y tras ello se pasa a la fase de "Escrow" (custodia) en la que se permiten pocos cambios en el código de manera que los equipos de testeo puedan llevar a cabo sus pruebas sin tener demasiadas variaciones entre las diferentes builds.

Así es que lo que Dani habrá estado probando este fin de semana (entre, seguramente, 10 o 15 cosas más) y que está disponible en la zona de subscriptores de TechNet y MSDN es la Escrow de la Beta 3, es decir una build que se modificará poco en cuanto a funcionalidad y que será la base de la Beta 3 que saldrá entre Abril y Mayo. Tiene suerte, porque el Padre Parada (que por cierto ha vuelto a la vida y por lo que se ve bastante afectado a nivel intelectual por este galimatías) y yo manejamos actualmente la build diaria, la build diaria de la rama de la Beta 3, y una build diaria específica para Windows Virtualization (que me tiene entusiasma-do).

Por supuesto, la última parte del proceso es la puesta en el mercado, con la versión RTM (Release To Manufacturing). Generalmente esa noche hay juerga por todo lo alto, pero al día siguiente el proceso vuelve a empezar en el punto donde se dejó, ya que hay que ponerse manos a la obra unos con la siguiente versión (Vienna en el caso de Windows), otros con el SP1.

Por último: ¿Dónde puedo conseguir una Beta de <tu producto favorito aquí>?

• Puede que en su Web pública dentro de la Web de Microsoft
• Puede que en Microsoft Connect: http://connect.microsoft.com
• Una buena forma de saber cual, cuando y donde es Beta Central: http://www.microsoft.com/technet/prodtechnol/beta/betacentral.mspx
• Seguro que con una subscripción a TechNet o MSDN, y vendrá rodeada de todos los productos finales, bien en un porta-CDs muy mono y/o descargables desde la Web

Saludos

Cuando lo he visto en La Pastilla Roja, no me lo podía creer:

Pero si, lo cierto es que una compañía suiza tiene entre su línea de productos de limpieza detergentes y suavizantes con el nombre de Linux y Micro&soft:

http://www.roesch-swiss.ch/?id=1161&cat_id=28

http://www.roesch-swiss.ch/?id=1161&cat_id=19

http://www.roesch-swiss.ch/?id=1161&cat_id=26

Ya me veo a alguno que yo me sé pregonando a los cuatro vientos que los que te venden abiertos le lavan mucho más blanco y por supuesto son mucho más seguros. Claro, y es que están hechos con una base de radicales libres aportados por la comunidad, y de esa manera su ropa le queda totalmente limpia de virus y malos olores.

Menos mal que para la limpieza del WC no hay nada por ahora ni en un sentido ni en el otro

Saludos

Hola

En el post anterior tocaba este tema por encima y Rolando pregunta en un comentario si podía dar detalles al respecto.

Pues bien, durante el desarrollo del Hypervisor de Longhorn, se han hecho algunos avances a la hora de programar cómo se sirven interrupciones, o IRQLs (Interrupt Request Levels), que definen la prioridad de hardware a la que el procesador está operando en un momento dado a la hora de ejecutar una instrucción asociada a un proceso. En el mundo de las máquinas multiprocesador virtuales, estas operaciones resultan especialmente "caras" en términos de rendimiento, por lo que servicios que demanden de forma intensa este tipo de operaciones pueden acabar atascadas en este cuello de botella. De hecho se ha comprobado que este problema solamente afecta a las versiones de 2003 de 32-bit (x86) La solución ha consistido en procesar estas operaciones por lotes, es decir coleccionar todas las operaciones que requieran la misma prioridad y procesarlas en conjunto, de modo que necesitamos acceder al hardware de forma menos frecuente y por tanto más efectiva.

Por tanto, esta optimización solo afecta a máquinas virtuales SMP con Windows Server 2003 de 32-bit. Dado que salvo en Windows Server Virtualization de Windows Longhorn Microsoft no tiene ningún producto de virtualización que permita generar "guests" multiprocesador/multicore, sólo será útil si se están creando este tipo de máquinas virtuales usando otras plataformas de virtualización.

Y hablando de todo un poco, hoy espero tener montado un Hypervisor y un System Center Virtual Machine Manager Beta2. J

Saludos

Hola

Ya está listo el SP2 de Windows Server 2003 en castellano para la arquitectura x86, tanto como archivo individual como el ISO. Dado que las versiones de Windows Server 2003 de x64 no están localizadas (traducidas) al castellano, no hay lógicamente Service Pack correspondiente y deberemos usar el inglés e instalar después una pequeña actualización del MUI para el SP2 ( http://support.microsoft.com/kb/925148 ).

Ejecutable: http://www.microsoft.com/downloads/details.aspx?familyid=95AC1610-C232-4644-B828-C55EEC605D55&displaylang=es

Imagen ISO: http://www.microsoft.com/downloads/details.aspx?familyid=1B9FE9E4-1D57-4698-A5CF-DB271ED6D90A&displaylang=es

Además de incluir todas las actualizaciones de seguridad hasta la fecha y cierto número de actualizaciones del sistema, cabe destacar las siguientes funcionalidades adicionales:

• Windows Deployment Services (WDS): Útil para el despliegue de Vista y de Longhorn usando el formato de imágenes del sistema .WIM, entre otras cosas
• Mejoras en la configuración Wireless, con soporte a WPA2 en las GPOs para configuración de clientes a través de Directorio Activo
• Simplificación de la gestión de las políticas de IPSEC
• Tools, tools, tools: MMC 3.0, ICACLS, DCDiag, MSConfig..
  • Hay un sysprep nuevo para SP2

    http://www.microsoft.com/downloads/details.aspx?familyid=93F20BB1-97AA-4356-8B43-9584B7E72556&displaylang=es

  • Support Tools Actualizadas

    http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90&displaylang=en

• Mejora del rendimiento cuando Windows Server 2003 SP2 y SQL son virtualizados con Virtual Server 2005

Como curiosidad, el SP2 de 2003 también vale para la versión x64 de Windows XP (comparad este enlace con este otro)

Algunas recomendaciones:

1. Antes de instalar,

• Leerse la Deployment Guide:

  http://technet2.microsoft.com/WindowsServer/en/library/c050419b-98a2-4802-b719-629a33a332391033.mspx?mfr=true

• Usar la Hotfix Scan Tool para buscar hotfixes que puedan tener un riesgo al sufrir una regresión con el SP2

  http://www.microsoft.com/downloads/details.aspx?familyid=eff8438f-8cc9-43eb-85c7-14dfcc099ee8&displaylang=en

1. Después de instalar, usar la KB Analyzer Tool

   http://support.microsoft.com/kb/931941/en-us

Más información de todo esto, aquí:

http://www.microsoft.com/technet/windowsserver/sp2/overview.mspx

Saludos