¡Un post cortito para hoy! Me topé con esto mientras configuraba la nueva función de Azure Synapse Link para Dataverse en un entorno.
La mayoría de las veces, cuando configuro recursos en Azure, lo hago como «Owner» de una suscripción o de un grupo de recursos. Esto significa que trabajo en modo dios todo el tiempo y no tengo algunos problemas que sí se encuentran los usuarios con menos derechos de acceso.
Después de mucho, mucho, mucho, mucho, mucho tiempo esperando, por fin está aquí la funcionalidad de desarrollo local de Dynamics 365 F&O… en preview pública. Es un poco diferente desde la primera vez que oímos hablar de esto en el MBAS de 2019… pero abre un nuevo escenario para los desarrolladores.
No voy a entrar en muchos detalles sobre la nueva experiencia unificada para desarrolladores, que así se llama ahora, pero si quieres saber qué necesitas para usarla y cómo configurarla, puedes leer esta entrada del blog de Aurélien Clere: Dynamics 365 FinOps Unified developer experience.
Hoy explicaré qué es Microsoft Dev Box y cómo podemos utilizarlo con las herramientas de desarrollo local de Dynamics 365 F&O. También conoceremos el coste, y en qué escenarios podríamos beneficiarnos de Microsoft Dev Box como nuestro entorno de desarrollo. Ya sabéis, lo mejor de los dos mundos, o lo peor… 🤣.
Pero antes…
Hoy vengo con un post sobre Dynamics 365 F&O, pero con el foco principal en la seguridad, concretamente en Microsoft Sentinel. Hace unos días se anunció que se había publicado una solución de Microsoft Sentinel para F&O que actualmente está en preview. ¡Vamos a aprender un poco sobre ella!
A veces pasamos por alto los aspectos de seguridad de las cosas que no están directamente relacionadas con F&O, especialmente en lo que se refiere a recursos como redes, cuentas de almacenamiento, máquinas de desarrollo, Microsoft Entra ID (¡este es el nuevo nombre de Azure AD!) o el uso de Bastion.
Y lo hacemos no porque no nos preocupe la seguridad, sino porque somos gente de Dynamics 365, y a veces puede que nos falten conocimientos en otras cosas. Si tienes suerte, contarás con un equipo de seguridad interno que se encargará de eso, si no, tendremos que aprender un poco.
Es la primera vez que uso Microsoft Sentinel, y seguro que me estoy perdiendo muchas cosas y funciones. Es hora de aprender.
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.
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.
AVISO: a raíz de este comentario en Linkedin quiero aclarar que estos rangos servirían para comunicación entrante a Dynamics 365 o el servicio que fuera. Para la comunicación saliente ver este documento en Learn: For my Microsoft-managed environments, I have external components that have dependencies on an explicit outbound IP safe list. How can I ensure my service is not impacted after the move to self-service deployment?
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.
Hoy, vamos a ver los pasos para configurar Azure Bastion para las VMs de desarrollo de Dynamics 365 Finance and Operations.
Vamos a hablar de los logs en Dynamics 365 Finance and Operations. Y no me refiero a los logs de la base de datos que hemos tenido desde los viejos tiempos de Axapta. Me refiero a los logs a secas, una tabla y un formulario para ver cómo/por qué cambian los datos, o el registro de llamadas externas a OData o servicios web personalizados en el ERP. Es algo que estoy seguro de que casi…
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.
Se ha publicado una nueva versión de las tareas para nuestros pipelines que usan los agentes de Azure. Estos cambios se han introducido recientemente para dar soporte a las librerías de autenticación MSAL para la conexión de LCS que utilizamos para subir y desplegar los deployable packages.
Las conexiones que tenemos ahora usan la Azure Active Directory (Azure AD) Authentication Library (ADAL), y el soporte para ADAL va a terminar en junio de 2022.
Esto quiere decir que si no actualizamos las tareas de Asset Upload y Asset Deployment a las nuevas versiones (1.* y 2.* respectivamente) los pipelines de release podrían dejar de funcionar después del 30 de junio de 2022.
Ahora que Microsoft va a actualizar los entornos sandbox adicionales de Dynamics 365 Finance and Operations, los partners y clientes solo nos tendremos que ocupar de los entornos hospedados en la nube (cloud-hosted environments), como hemos hecho siempre.
Estoy seguro de que cada equipo gestiona esto a su manera, quizá dejando que cada desarrollador actualice su máquina, o que hay alguien en el partner que se lo hace. Y eso en el mejor de los casos, quizá nadie actualiza las máquinas de desarrollo…
Si quieres saber más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
¡Hoy os traigo un script de PowerShell que podemos ejecutar en un pipeline para actualizar automáticamente todas las máquinas de desarrollo!
Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
Mover datos desde producción a un entorno sandbox es algo que tenemos que hacer regularmente para tener datos reales para testear o debugar. Es un proceso lento que requiere de bastante tiempo y que se puede automatizar como expliqué en el post LCS DB API: automatizando la copia de la DB de Prod a Dev.
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 leer más sobre la API REST del DMF, que voy a usar, leyendo este post de Fabio Filardi: Dynamics 365 FinOps: Batch import automation with Azure Functions, Business Events and PowerBI.
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:
Mi nuevo libro:
«Extending Dynamics Finance and Operations Apps with Power Platform»
¡Ya está a la venta!
