10 razones para amar Windows Server 2016

Presentación del tema: "10 razones para amar Windows Server 2016"— Transcripción de la presentación:

1 10 razones para amar Windows Server 2016
Amado Millones Fache Windows Server Product Manager Noviembre 2016

2 El área de IT está tironeada en dos direcciones
Brindar soporte a la agilidad e innovación en el negocio Brindar recursos IT seguros y controlados Para 2017, el 50% del total del gasto IT se realizará por fuera de la organización IT formal Tension to move faster – Add more pain tpointes

3 Puntos de diseño de Windows Server
Brinda seguridad en capas para amenazas emergentes 1 Arma un centro de datos definido por software 2 Crea una plataforma de aplicación optimizada en la nube 3

4 10 razones para amar Windows Server 2016
1. Directorio Activo 2. Seguridad 3. Cómputo 4. Red 5. Almacenamiento 6. Servicios de escritorio remoto (RDS) 7. Nano Servidor 8. Contenedores 9. PowerShell 10. Herramientas de gestión del servidor (SMT)

5 10 razones para amar Windows Server 2016
SEGURIDAD SDDC 1. Active Directory 2. Máquinas virtuales blindadas 3. Cómputo 4. Red 5. Almacenamiento 6. Remote Desktop Services (RDS) PLATAFORMA DE APLICACIÓN ADMINISTRACIÓN 7. Nano Server 8. Contenedores 9. PowerShell 10. Server Management Tools (SMT)

6 Identidad privilegiada

7 Desafíos para proteger credenciales
Microsoft Build 2016 9/20/2018 2:55 PM Desafíos para proteger credenciales La ingeniería social lleva al robo de credenciales La mayoría de los ataques incluye recolección de credenciales (PtH) Las credenciales administrativas suelen brindar derechos extra innecesarios durante tiempo ilimitado ADMIN DOMINIO BEN MARY JAKE ADMIN Administrador típico Capacidad Tiempo © 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

8 Enfoque Windows Server 2016
Microsoft Build 2016 9/20/2018 2:55 PM Enfoque Windows Server 2016 Credential Guard Previene ataques del tipo ‘Pass the Hash’ y ‘Pass the Ticket’, ya que protege las credenciales almacenadas a través de seguridad basada en virtualización Just Enough La administración limita los privilegios administrativos al mínimo conjunto de acciones (limitado en el espacio) Just in Time La administración otorga acceso privilegiado a través de un flujo de trabajo que es auditado y limitado en el tiempo JEA + JIT = limitada en tiempo y capacidad ADMIN DOMINIO BEN MARY JAKE ADMIN Administración Just Enough y Just in Time Typical administrator Capacidad Capacidad y tiempo requeridos Tiempo © 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

9 Proteja infraestructura y aplicaciones

10 Desafíos para proteger el sistema operativo
Nuevos exploits pueden atacar la ruta de inicio del sistema operativo hasta las operaciones de aplicaciones Las amenazas conocidas y desconocidas deben ser bloqueadas sin impactar en las cargas de trabajo legítimas ? ?

11 Enfoque Windows Server 2016
Control Flow Guard Protege contra vulnerabilidades desconocidas bloqueando los vectores de ataque comunes Windows Defender Protege activamente de malware conocido sin impactar en las cargas de trabajo Code Integrity Asegura que solo los binarios permitidos se pueden ejecutar desde el momento en que se inicia el sistema operativo

12 Máquinas virtuales blindadas

13 Proteja las máquinas virtuales
9/20/2018 Proteja las máquinas virtuales Un administrador comprometido o malintencionado de cualquier fabric puede acceder a máquinas virtuales huéspedes La salud del host no se tiene en cuenta antes de ejecutar las máquinas virtuales Las máquinas virtuales de los inquilinos están expuestas a ataques de almacenam. y redes Las máquinas virtuales no pueden aprovechar las capacidades de seguridad enraizadas en hardware, como TPMs Hypervisor Fabric Almacenamiento Host OS Cliente MV huésped Cliente Fabric Hypervisor MV huésped Host sano? Goal:  Continue with the premise of: “Making Virtual machine security in par with the physical machine security” Show the differences today between virtual machines and physical machines If you cannot log into the physical machine you need to go and grab the machine physically and take it out A VM you can just pick up from storage, network or if you can log into the host We work to change this equation with Shielded virtual machines so that a VM is as secure as a physical machine. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

14 Enfoque Windows Server 2016
Máquinas virtuales blindadas Use BitLocker para cifrar el disco y máquinas virtuales de última generación para proteger secretos de admins comprometidos y malware Host Guardian Service Autentifique la salud del host liberando las claves necesarias para iniciar o migrar una máquina virtual solo a hosts sanos Máquinas virtuales de 2 Gen. Soporta equivalentes virtualizados de tecnologías de seguridad de hardware (ej., TPMs) y permite encriptación BitLocker para máquinas virtuales blindadas PERÍMETRO EDIFICIO SALA DE COMP HYPER-V HYPER-V Máquina física Máquina virtual Máquina virtual blindada Server Administrator ü û * S torage administrator ü û Network administrator ü û Backup operator ü û Virtualization-host administrator ü û *Configuration dependent Virtual machine administrator û ü

15 Claves de desencriptación controladas por sistema externo
Nube/ Centro de datos Host OS Guest VM Guest VM Guest VM Conrolador de fabric Hypervisor Hyper-V Host 1 Por favor, señor, ¿puede darme unas claves? Host OS Hypervisor Guest VM Hyper-V Host 2 Host OS Hypervisor Guest VM Hyper-V Host 3 Protección de claves Host Guardian Service

16 Política de liberación de clave para entornos de confianza
Criterio de liberación de claves (TPM-mode) Máquinas físicas conocidas Instancia Hyper-V de confianza Configuración según CI Nube/ Centro de datos Cloud/Datacenter Host OS Guest VM Guest VM Guest VM Conrolador de fabric Controller Fabric Hypervisor Hyper-V Host 1 Claro, te conozco y pareces sano Host OS Hypervisor Guest VM Hyper-V Host 2 Host OS Hypervisor Guest VM Hyper-V Host 3 Protección de claves Host Guardian Service

17 Nano Server

18 Nano Server: Sistema operativo ‘Just Enough’
9/20/2018 Nano Server: Sistema operativo ‘Just Enough’ Optimizada para aplicaciones distribuidas de próxima generación Mayor densidad y menor superficie de ataque y requisitos de mantenimiento Marco de trabajo para aplicaciones distribuidas de próxima generación Interopera con aplicaciones de servidor existentes Aplicaciones de terceros Experiencia RDS GUI total Cargas de trabajo especializadas Cargas de trabajo de MV tradicionales Server Core Menor mantenimiento Entorno de servidores Contenedores y aplicaciones modernas Just enough OS: Simplified deployment Improved resource utilization Reduced servicing requirements Nano Server Just Enough OS © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

19 Nano Server: próximos pasos en el viaje hacia la nube
Modelo “huella cero” Los roles de servidor y características opcionales viven por fuera del Nano Server Paquetes independientes que se instalan como aplicaciones Principales roles y características Hyper-V, almacenamiento (SoFS), armado de clusters Servidor IIS y DNS disponible en TP4 Core CLR y ASP.NET 5 Soporte total para driver de Windows Server Paquete antimalware opcional Soporta System Center VMM y agente OM

20 Administración remota de Nano Server
No solo línea de commando Server Manager Hyper-V Manager Failover Cluster Mgr PerfMon, Event Viewer, etc. Server Management Tools (SMT) – nuevo GUI remoto basado en la web PowerShell Core

21 Contenedores

22 9/20/2018 2:55 PM Contenedores Un nuevo enfoque para armar, enviar, desplegar e instanciar aplicaciones Las aplicaciones solían armarse y desplegarse en sistemas físicos con una relación 1:1 Las nuevas aplicaciones suelen requerir nuevos sistemas físicos para el aislamiento de recursos Físico/Virtual Empaquete y ejecute aplicaciones dentro de contenedores Física Mayor índices de consolidación y mejor utilización Despliegue más veloz que en los entornos físicos tradicionales Las aplicaciones se despliegan en MVs con mayor éxito de compatibilidad Las aplicaciones se benefician con las características principales de las MV, como la migración en vivo, HA Principales beneficios Mayor aceleración de despliegue de aplicaciones Reduce esfuerzo en el despliegue de aplicaciones Mejora el desarrollo y las pruebas Menores costos asociados con el despliegue de aplicaciones Aumento en la consolidación de servidores When it comes to applications, historically, IT administrators deployed with a 1:1 application to server ratio. When a new application was required by the business, it was deployed onto a newly provisioned physical system, to ensure no conflicts with existing applications and workloads. This resulted in a huge number of physical servers, all with very low utilization. Fast forward to a more modern datacenter, where virtualization is now prevalent, and you’ll find significantly higher consolidation ratios, much greater utilization and significantly accelerated app deployment speeds as administrators deploy applications in minutes, compared with hours, days or weeks in a purely physical datacenter. Compared with applications that ran on individual physical servers, the compatibility of those same apps to run inside virtual machines was typically very high. After all, the virtual machine just presents virtual hardware to the same operating system that was running in the physical world. The only consideration being, if that application or workload has a requirement for a specific piece of hardware, such as a PCI-E card, that couldn’t be virtualized and presented through to the guest operating system. In addition, once that application was encapsulated inside the virtual machine, it benefited from higher levels of redundancy, and also mobility, through features such as live migration. There is however, a new and increasingly popular way to build, ship, deploy and instantiate applications. Containers can further accelerate application deployment and streamline the way IT operations and development teams collaborate to deliver applications to the business. But what are containers? Well, to give the computer science definition, containers are an operating system-level isolation method for running multiple applications on a single control host. With developers building, and then packaging their applications into containers, and providing them to IT to run on a standardized platform, it reduces the overall effort to deploy applications, and can streamline the whole dev and test cycle, ultimately reducing costs. As containers can run on a host OS which itself could be physical or virtual, it provides IT with flexibility, and the opportunity to drive an increased level of server consolidation, all whilst maintaining a level of isolation that allows many containers to share the same host operating system. Virtual © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

23 9/20/2018 2:55 PM ¿Por qué contenedores? Las aplicaciones impulsan la innovación en el mundo móvil en la nube actual Desarrolladores Desbloquean la productividad y la libertad Habilitan aplicaciones que se escriben una vez y se despliegan donde sea Se pueden desplegar como aplicaciones distribuida en multi-capas en modelos IaaS/PaaS Ofrecen abstracción para microservicios DevOps Operaciones Mejora modelos de despliegue IT familiares Ofrece entornos estandarizados para equipos de desarrollo, QA y producción Reduce diferencias en distribuciones de OS e infraestructura subyacente Mayor utilización/ densidad de cómputo Rápida variación de escalado en respuesta a cambios en las necesidades empresariales But why do we need containers? What do containers provide that virtual machines can’t? Who is driving the momentum behind containers? Applications are fueling the innovation in today’s cloud-mobile world, and developers hold the keys to the power of those applications. The more streamlined and efficient the process for developers to build and deliver their applications, the faster that more powerful applications can reach the business. This however, has to work across both the developers, and IT who hold the keys when it comes to the infrastructure that the applications will run on. For the developers, containers unlock huge gains in productivity, and freedom – the ability to build an application, package within a container, and deploy, knowing that wherever you deploy that container, it will run without modification, whether that is on-premises, in a service provider’s datacenter, or in the public cloud, using services such as Microsoft Azure. These containers don’t have to be deployed independently – developers can model complex multi-tier applications, with each tier packaged within a container, and these can be distributed across IaaS and PaaS models, again, increasing the overall surface area that the developer can aim for when releasing their application. This powerful abstraction of microservices provides developers with incredible potential to deliver applications more rapidly than ever before. They can’t however, do it without the Operations’ team support. On the Operations side, they benefit considerably by being able to gain ever higher levels of consolidation for applications and workloads than even virtualization could provide, and in addition, they can put in place a platform that can rapidly scale up and down to meet the changing needs of the business. This standardized platform is easier to manage, yet provides the developers with a consistent environment into which they can simple provide their app, and hit ‘run’. This integration across development and operations is what’s becoming known in the industry as DevOps. DevOps aims to integrate people, process and tools to streamline the application development and deployment process. Ops can focus on providing a standardized infrastructure and a set of resources that can be consumed by the development teams, and developers can focus on designing, building, packaging and testing their applications, utilizing the platform that IT provide. Integra personas, procesos, y herramientas para un proceso de desarrollo de aplicación optimizado Las operaciones se centran en infraestructura estandarizada Los desarrolladores se centran en armar, desplegar y probar las aplicaciones © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

24 Contenedores Windows Server Anatomía y principales capacidades
9/20/2018 2:55 PM Contenedores Windows Server Anatomía y principales capacidades Principales capacidades Contenedor A Contenedor B Contenedor C Armado: los desarrolladores usan herramientas de desarrollo conocidas, como Visual Studio, para las aplicaciones que se ejecutan en los contendores Al armar aplicaciones modulares que usan contenedores, los módulos pueden escalar de manera independiente, y actualizarse a un ritmo independiente Ejecución: capacidades del contenedor incluidas en Windows Server Administración: despliegue y administración de contenedores usando PowerShell, o usando Docker Recursos: defina los recursos de CPU y memoria por contenedor junto con desempeño de almacenamiento y red Red: ofrece IP DHCP/static o NAT para conectividad de la red Capa de web Capa de app Capa DB LOB app (+Binarios) LOB app (+Binarios) LOB app (+Binaries) Bibliotecas (Se comparten con contenedores) Bibliotecas So what are some of the core Windows Server container capabilities. The first key takeaway, is that there is core functionality for containers, supported natively within the kernel, and they will be available in the next release of Windows Server. Developers will use familiar development tools, such as Visual Studio, to write apps to run within containers. Instead of trying to backport existing applications, by building modular apps leveraging containers, modules can scale independently, and be updated on independent cadences, providing the developer with much greater flexibility and speed. Applications can rely on other packages to provide core functionality. As you can see from the graphic, there are 2 containers that are sharing a number of libraries. In addition, when packaging, the packages also depend on a base package which describes the underlying operating system, such as Server Core, which has a large number of APIs that Windows supports, such as .NET, IIS etc. Nano Server is another, however this has a much smaller surface, that will target apps that have been written from the ground up, with the cloud in mind. Containers are isolated behind their own network compartment. This can be provided a NAT DHCP or Static IP. Each container has an independent session namespace, which helps to provide isolation and additional security. The kernel object namespace is isolated per container. Each container also has access to certain CPU and memory resources, along with storage and network capacity – these are controlled by the administrator, and ensures predictable and guaranteed control of processes. These containers can be managed using tools such as PowerShell, or using the Docker management tools. Host OS c/soporte para contenedor Servidor (Físico o Virtual) © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

25 Contenedores Windows Creación, despliegue y gestión
9/20/2018 2:55 PM Contenedores Windows Creación, despliegue y gestión Los desarrolladores actualizan, repiten y despliegan contenedores actualizados 2 Servidores físicos/virtuales Las operaciones automatizan el despliegue y monitorean las aplicaciones desplegadas desde el repositorio central 3 Las operaciones colaboran con desarrolladores para ofrecer métricas y datos sobre las aplicaciones So what does a lifecycle look like? Firstly, developers build and test their applications, in containers, on their own box. This could be using a development environment like Visual Studio, or one from a 3rd party. You’ll see in this case, there is a couple of different containers, perhaps representing 2 tiers of an application or workload. Once completed, these containers are pushed to central repository. This could be a Docker repository, which you’ll learn more about later. Operations automates deployment of the containers, from this central repository, to the target machines, which could be physical or virtual. They continue to monitor the containers… …and collaborate with developers to provide them with insight and monitoring metrics which help the development teams gain insight into the usage of the applications. This could be used to drive an update to a particular container, which, with the developers perform on their own boxes, iterate a version, and deploy the updated version to the central repository, which in turn, is then used to update the existing deployed containers. They could also, if they wanted, to roll it back to a previous version. Containers provides considerable flexibility in this space. Los desarrolladores arman y ponen a prueba aplicaciones en contenedores, usando un entorno de desarrollo, como Visual Studio 1 2 Los contenedores son empujados al repositorio central © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

26 Contenedores Hyper-V Anatomía y principales capacidades
9/20/2018 2:55 PM Contenedores Hyper-V Anatomía y principales capacidades Hyper-V Container Hyper-V Container Principales capacidades Consistencia: Los contenedores Hyper-V usan las mismas APIs que los contenedores de Windows Server, asegurando la consistencia en las herramientas de gestión y despliegue. Compatibilidad: Los contenedores Hyper-V usan las mismas imágenes que los contenedores Windows Server. Fuerte aislamiento: cada contenedor Hyper-V tiene su propia copia dedicada del núcleo Alta confianza: con tecnología de virtualización Hyper-V comprobada Optimizados: la capa de virtualización y el sistema operativo se optimizaron específicamente para los contenedores App A Bins/Bibliotecas App B Bins/Bibliotrcas OS invitado Windows Optimizado para cont. Hyper-V OS invitado Windows Optimizado para cont. Hyper-V Hyper-V Containers take a slightly different approach to containerization. To create more isolation, Hyper-V Containers each have their own copy of the Windows kernel and have memory assigned directly to them, a key requirement of strong isolation. We use Hyper-V for CPU, memory and IO isolation (like network and storage), delivering the same level of isolation found in VMs. Like for VMs, the host only exposes a small, constrained interface to the container for communication and sharing of host resources. This very limited sharing means Hyper-V Containers have a bit less efficiency in startup times and density than Windows Server Containers, but the isolation required to allow untrusted and “hostile multi-tenant” applications to run on the same host. So aren’t Hyper-V Containers the same as VMs? Besides the optimizations to the OS that result from it being fully aware that it’s in a container and not a physical machine, Hyper-V Containers will be deployed using the magic of Docker and can use the exact same packages that run in Windows Server Containers. Thus, the tradeoff of level of isolation versus efficiency/agility is a deploy-time decision, not a development-time decision – one made by the owner of the host. Hypervisor Servidor © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

27 Contenedor Windows Server
9/20/2018 2:55 PM Integración con Docker Inversiones estratégicas unidas para impulsar contenedores Docker: Un motor de fuente abierta que automatiza el despliegue de las aplicaciones como un contenedor portátil y auto–suficiente que se puede ejecutar casi en cualquier lugar Socios: permite que las herramientas de Docker gestionen aplicaciones con múltiples contenedores usando contenedores Linux y Windows, sea cual fuere el entorno de alojamiento o proveedor de la nube Centro de datos del cliente Dockerized app Contenedor Windows Server Contenedor Linux En cualquier lugar Microsoft Azure Proveedor de servicio We’ve mentioned Docker a number of times already – what is Docker? At a high level, Docker is an open source engine that automates the deployment of any application as a portable, self-sufficient container that can run almost anywhere. Back in June 2014, Microsoft Azure added support for Docker containers on Linux VMs, enabling the broad ecosystem of Dockerized Linux applications to run within Azure’s industry-leading cloud. In October 2014, Microsoft and Docker Inc. jointly announced bringing the Windows Server ecosystem to the Docker community, through investments in the next wave of Windows Server, open-source development of the Docker Engine for Windows Server, Azure support for the Docker Open Orchestration APIs and federation of Docker Hub images in to the Azure Gallery and Portal. Many customers are running a mix of Windows Server and Linux workloads and Microsoft Azure offers customers the most choice of any cloud provider. By supporting Docker containers on the next wave of Windows Server, we are excited to make available Docker open solutions across both Windows Server and Linux. Applications can themselves be mixed; bringing together the best technologies from the Linux ecosystem and the Windows Server ecosystem. Windows Server containers will run in your datacenter, your hosted datacenter, or any public cloud provider – and of course, Microsoft Azure Docker Inversiones en la próxima ola de Windows Server Despliegue Open source de Docker Engine para Windows Server Azure soporta APIs de Docker Open Orchestration Federación de imágenes Docker Hub para Azure Gallery y Portal Inversiones estratégicas © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

28 Windows Server 2016 Nuevo Esquema de Licenciamiento

29 9/20/2018 Licenciamiento Window Server 2016 Licenciamiento de core basado en consumo Los nuevos modelos de computación permiten una mayor movilidad de los datos y aplicaciones entre en las instalaciones y la nube Pasando a Modelo de licencia Core establece una “moneda común” para el cálculo de los recursos en las instalaciones o en la nube Alinea a la evolución de la tecnología en el cambio de hardware para la densidad del núcleo más no del procesador In the past the licensing combined the notions of hardware (CPUs) and virtualization (VM). Where we're going separates these two ideas. We will still license hardware but via cores (instead of procs) and ONLY AFTER we license the hardware will be address virtualization. Let's explain why we're doing this and how it'll work. New License Principles Customers are increasingly demanding a hybrid IT environment that spans both on-premises and cloud and allows mobility of data and apps between the two. The new licensing model reflects the need to enable portability of apps and data by creating a “common currency” for computing resources whether they’re located on-premises or in the cloud. More accurately reflect the evolution of hardware technology which now delivers performance by packing more cores into each processor instead of adding more processors to each server. Core based licensing provides a more consistent licensing metric regardless of where the solution is deployed, whether it is on-premises or in a cloud. A minimum of 8 core licenses is required for each physical processor in the server and a minimum of 16 cores is required to be licensed for servers with one processor. When all the cores have been licensed, a customer obtains rights to use 2 virtual machines (VMs). Standard Edition provides rights for up to 2 OSEs or Hyper-V containers when all physical cores in the server are licensed. Multiple licenses can be assigned to the same cores for additional OSEs or Hyper-V containers. For example, to obtain 2 additional VMs for Standard edition, simply re-license all the physical cores on the server. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

30 Overview: Cambio de modelo de licenciamiento (procesador a core)
9/20/2018 2:55 PM Overview: Cambio de modelo de licenciamiento (procesador a core) ¿Qué cambia? ¿Cómo se manejará? Todos los cores físicos del servidor deben ser licenciados Cada servidor debe tener un mínimo de 16 cores licenciados.(hoy son 2 CPUs) Cada procesador debe estar licenciado al menos con 8 cores El derecho para 2 VMs* (Standard) será otorgado solo cuando todos los cores que tiene el servidor sean debidamente licenciados. Para VMs adicionales, todos los cores tienen que ser licenciados de nuevo. 1 CPU / 4 Cores 1 CPU / 4 Cores Rights to 2 CPU and 2 VM Rights to 16 cores Proc Cores/ Proc # VMs # of Cores to be licensed Regla # Price vs. WS2012R2 1 4 2 16 1 Same Ediciones Standard y Datacenter serán licenciadas por # de cores El licenciamiento base de WS2016 otortga derecho a 16 cores y el costo será el mismo a un licenciamiento basado por procesador como en WS2012R2 Licenciamiento adicional estará disponible si necesitan licenciarse más cores Requiere CALs Customers are increasingly demanding a hybrid IT environment that spans both on-prem and cloud and allows mobility of data and apps between the two. The new licensing model reflects this reality by creating a “common currency” for computing resources whether they’re located on-prem or in the cloud. Additionally, the new licensing model more accurately reflects the evolution of hardware technology which now delivers performance by packing more cores into each processor instead of adding more processors to each server. 2 2 2 16 1 Same 2 2 4 32 3 Same 4 2 2 32 2 Same 4 8 4 64 2 2x * Each additional core is priced at 1/16 the price of a base license. Additional licenses are available in packs of 2, 4, or 16 cores). * Hyper-V Containers are licensed identically to VMs. © 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

31 Windows Server 2016 Licensing Licenciamiento basado en cores físicos – tres reglas básicas
Todos los cores físicos licenciados Core Procesador Mínimo de licencias por procesador = 8 cores, aún así existan menos cores 2 Price to license 16 cores is same as price for current 2 Proc ‘base’ license. With WS2016, a base license will grant rights for 16 cores. Additional licenses can be purchased to cover extra cores. CALs are required for Std and DC. Important to separate hardware licensing from VM licensing (this is an important departure from today’s licensing paradigm All the following Reglas must hold: Regla #1: Every physical core on the server must be licensed (‘covered’). No VM rights are granted until all cores are licensed. When all the cores have been licensed, a customer gets rights for 2 VMs. Regla #2: Every processor must be licensed to cover a minimum of 8 cores Regla #3: Every server must be licensed to cover a minimum of 16 cores There are 3 licensing Reglas to follow License all of the physical cores on the server Ensure every processor is licensed to cover a minimum of 8 cores Ensure every server is licensed to cover a minimum of 16 cores 3 Mínimo de licencias por servidor= 16 cores, aún así existan menos cores Servidor Físico

32 Escenarios de Licenciamiento – Contando Cores
El cliente quiere licenciar ¿Cuántos cores licenciados necesita el cliente? 1 Respuesta: 16 por la Regla #2 (o Regla #3) ¿Por qué? Regla #2: cada procesador debe estar licenciado para cubrir mínimo 8 cores (2 x 8 = 16) o Regla #3: cada Sistema debe estar licenciado por un mínimo de 16 cores 1 servidor físico 2 proc 4 cores cada uno 1 2 1 servidor físico 1 proc 8 cores cada uno 2 Respuesta: 16 por la Regla #3 ¿Por qué? Regla #3: cada Sistema debe estar licenciado por un mínimo de 16 cores * Edge case – when OEM has disabled cores, customer does not have to pay for licenses for disabled cores, until they are enabled by the OEM 1 servidor físico 2 proc 12 cores cada uno 3 3 Respuesta: 24 por la Regla #1 ¿Por qué? Regla #1: Todos los cores físicos en el servidor deben estar licenciados

33 Recursos Cómo empezar con Windows Server 2016 Descargue la evaluación
windows-server-technical-preview Obtenga la documentación us/library/mt126143(v=ws.12).aspx Mire videos técnicos Contáctenos via Twitter, o en los blogs de Windows Server Blogs

34