Si estás integrando Dynamics 365 Finance & Operations con terceros, y tu organización o la del tercero están usando un firewall, puede que te hayas encontrado en el escenario de que te pregunten «¿cuál es la dirección IP del entorno de producción/sandbox?».
Pues bien, no lo sabemos. Sabemos que IP tiene ahora, pero no sabemos si tendrá la misma IP en el futuro, tendrás que hacer un monitoreo de esto si planeas abrir IPs únicas. Esto es algo que Dag Calafell escribió en su blog: Static IP not guaranteed for Dynamics 365 for Finance and Operations.
Monitoreo a ojo
Así que, ¿qué tengo que hacer si tengo un firewall y necesito permitir el acceso a/desde Dynamics 365 F&O o cualquier otro servicio de Azure? Al equipo de red no le suele gustar la respuesta: si no puedes permitir un FQDN, debes abrir todos los rangos de direcciones para el centro de datos y el servicio al que quieres acceder. Y eso son muchas direcciones que hacen que el equipo de red se ponga triste.
En el post de hoy, os mostraré una forma de monitorear los rangos proporcionados por Microsoft, y espero que nos haga la vida más fácil.
Llevamos mucho tiempo trabajando con las VM de desarrollo de F&O, sobretodo los partners de Microsoft que necesitan poder cambiar rápida y fácilmente entre diferentes entornos de clientes, y utilizar el VHD es un poco más complicado en ese escenario.
Y por supuesto, usamos RDP para conectarnos a estas VMs. RDP es poco seguro, debido a su débil cifrado, su uso generalizado y la falta de funciones de seguridad integradas en el protocolo. Por lo tanto, los hackers a menudo se centran en RDP para obtener acceso no autorizado a los sistemas. Puedes leer más sobre cómo proteger sus máquinas virtuales en Best practices for defending Azure Virtual Machines.
Con Bastion estás tan seguro como con Gandalf!
Hoy, vamos a ver los pasos para configurar Azure Bastion para las VMs de desarrollo de Dynamics 365 Finance and Operations.
¡Estoy de vuelta con información adicional sobre Azure API Management! Más contenido de Azure, y probablemente seguiré escribiendo más posts relacionados con Azure en el futuro.
Creo que hay muchas formas de aprender cosas nuevas, y para mí, dos de ellas son escribir artículos en el blog y utilizar nuevas tecnologías para resolver problemas en el trabajo. Por supuesto, mi objetivo es intentar aplicar los temas de Azure sobre los que escribo a Dynamics 365.
Hoy voy a presentar un enfoque de arquitectura para las integraciones, aprovechando el API Management y otros componentes de Azure, para Dynamics 365 o cualquier otra cosa que tenga un endpoint.
En el post de hoy, quiero hablar del uso de Azure API Management (APIM) junto con Dynamics 365 Finance and Operations.
Azure API Management es una plataforma de gestión híbrida y multi-nube para APIs en todos los entornos. Esto significa que, después de desplegar una cuenta de APIM, puedes crear una API que puede servir servicios de un sistema o de varios.
Yo pulsando el botón para subir un data package usando Azure DevOps
En este post voy a añadir un paso adicional al refresco de la base de datos: restaurar un data package (DP). ¿Por qué? Porque estoy seguro que todos necesitamos cambiar parámetros o endpoints en los entornos de test después de un refresco desde prod.
Puedes aprender más sobre la API REST de LCS leyendo estos posts que escribí hace un tiempo. Te puede interesar leerlos porque voy a dar por explicadas algunas cosas que voy a referenciar en este post:
Si habitualmente recibes los correos de notificación de LCS de tus proyectos ya sabrás esto: todas las máquinas Tier 1 gestionadas por Microsoft desaparecerán a partir del 1 de diciembre!
¿Como que desaparecerán?
Esto es lo que dice el correo:
As communicated previously, Microsoft is removing the use of Remote Desktop Protocol (RDP) to access environments managed by Microsoft. As RDP access is required for development, going forward customers will be required to develop using a Cloud Hosted Environment or download a local “Virtual Hard Disk” (VHD) within Lifecycle Services. Cloud Hosted Environments will allow customers to manage the compute, size, and cost of these environments. This infrastructure change will ensure that customers decouple development tools from any running environment.
In addition, effective November 1, Tier 1 environments will not be included in the purchase of Dynamics 365 Finance, Dynamics 365 Supply Chain Management, Dynamics 365 Project Operations, or Dynamics 365 Commerce apps. The ability to purchase additional Add-On tier 1 environments will also be removed at this time. Beginning December 1, Remote Desktop Protocol (RDP) access for the existing Tier 1 Developer environments, managed by Microsoft, will be removed and decommissioned. Customers will need to preserve or move data within these environments by this date. See the FAQ below with links to existing documentation.
Microsoft will continue to invest in development tools and processes to allow customers to extend the rich capabilities available within Dynamics 365. Learn about one of these key investments, which allows for build automation that uses Microsoft-hosted agents and Azure Pipelines. This approach helps customers avoid the setup, maintenance, and cost of deploying build virtual machines (VMs). It also reuses the existing setup of build agents to run other .Net build automation.
Azure credits will be provided for qualifying customers to use for deploying Tier 1’s using Cloud Hosted Environments. Complete this survey to submit your request.
Sinceramente ha sido un poco de sorpresa. Se había informado que los accesos por RDP iban a desaparecer como pone en el correo, y la desaparición de la máquina de build lleva siendo un rumor desde hace 2 años por lo menos. Pero esto es bastante drástico y ¡con muy poco tiempo de aviso! ¡Quedan menos de dos meses para diciembre!
Pero esperad… en vez de especular, Evaldas Landauskas ha preguntado a microsoft y parece que las máquinas no se borrarán de inmediato el día 1 sino progresivamente:
FYI: I have asked MS about this topic and this is the answer I have got.
"The process will start with removal of RDP and eventually we will decommission these environments after no activity."
So it won't be decomissioned immediately if it's in use.
Esta noche hemos recibido otro correo de LCS con más detalles y fechas actualizadas. Así que al final se ha aplazado todo un poco y este es el plan:
1 de noviembre de 2020: no se podrán desplegar ni adquirir más entornos Tier 1. Los que no estén desplegados se borrarán.
1 de diciembre de 2020: se eliminará el acceso por RDP.
30 de enero de 2021: se mandarán notificaciones sobre el parado y borrado de las VM Tier 1.
¿Qué hacer ahora?
Esto depende de qué uso estés haciendo de la máquina y si tienes entornos Tier 1 add-on. Y otra prgunta seguramente sea el coste de reemplazar esa máquina virtual.
Sólo la uso como servidor de build
Si sólo usas la máquina Tier 1 como servidor de build tienes dos opciones:
Necesitarás una máquina virtual de build si ejecutas tests o sincronizas la DB como parte de tu proceso de build. Es la única forma. Sobre los costes: podrías desplegar una VM de tipo B8MS con 2 discos SSD Premium de 128GB por unos 280€ al mes. Incluso se podría probar a usar una B4MS por unos 160€/mes.
Esto es más o menos lo mismo que cuesta una máquina Tier 1 de las gestionadas por Microsoft. Y si sólo ejecutas los tests y la sincronización una vez al día puedes rebajar los costes un poco más si arrancas y paras la VM desde tu pipeline.
Si no lo necesitáis, o queréis una build de CI que sólo compile el código, simplemente configurad las builds hospedadas de Azure.
La uso de máquina de desarrollo
Si usas máquinas gestionadas por microsoft add-on ara desarrollo tendrás que desplegar nuevas máquinas de desarrollo en tu suscripción (o la de tu cliente).
¿Preocupados por el coste extra? No lo estéis. Si desplegáis máquinas DS12 V2, con 3 discos SSD Premium de 128GB, y las usáis durante 8 horas al día, 20 días al més, el coste es de unos 120€ al mes.
En ambos casos, si leéis el correo, veréis que Microsoft dará créditos de Azure en compensación por estas VMs, pero no sabemos cuántos. Espero que esto haga la transición más sencilla pero estoy seguro que habrá bastante gente quejándose 😂
Este es otro post sobre resolver problemas en Dynamics 365 usando herramientas externas. De todas formas, empiezo a dejar de pensar en todo lo relacionado con Azure como algo no externo. En este caso mostraré distintos escenarios usando Azure functions con Dynamics 365.
Escribí esto hace tres semanas y tenía la intención de que fuera un post de dos partes, pero después de ver este fantástico post sobre Azure functions de Fabio Filardi no sé si podría añadir nada más y probablemente lo deje aquí. ¡Leedlo!
En este post veremos qué son las Azure functions, cómo crear una localmente y publicarla en Azure.
Después de la actualización dl último post sobre llamar a la API de LCS desde Azure DevOps me di cuenta que crear una pipeline con una contraseña a la vista no era muy seguro. ¿Cómo podemos añadir un extra de seguridad a pipelines? Una vez más podemos acudir a una herramienta de Azure para ayudarnos, Azure Key Vault.
Azure Key Vault
Key Vault es un servicio que nos permite guardar certificados o secretos de forma segura y usarlos en nuestras apps o servicios. Y como muchos otros servicios de Azure tiene un coste pero es muy bajo y, para un uso normal, la factura será de 1 céntimo o ninguno al mes. ¡No seáis rancios con la seguridad!
Hace no mucho hablé en otro post sobre la API de movimiento de base de datos de LCS, y en este quiero mostrar como llamar a la API usando PowerShell desde nuestras pipelines de Azure DevOps.
¿Para qué?
Básicamente por automatización. Ahora mismo la API sólo permite el refresco de un entorno de Microsoft Dynamics 365 for Finance and Operations a otro, así que la idea es tener datos frescos de producción en nuestros entornos de UAT a diario. No sé qué nuevas operaciones soportará la API en el futuro pero otra idea sería añadir al pipeline la exportación de la DB (creando un bacpac) de un entorno de UAT para tener datos listos para restarurar en una máquina de desarrollo.
