Azure Site Recovery
81 TopicsScaling Smart with Azure: Architecture That Works
Hi Tech Community! I’m Zainab, currently based in Abu Dhabi and serving as Vice President of Finance & HR at Hoddz Trends LLC a global tech solutions company headquartered in Arkansas, USA. While I lead on strategy, people, and financials, I also roll up my sleeves when it comes to tech innovation. In this discussion, I want to explore the real-world challenges of scaling systems with Microsoft Azure. From choosing the right architecture to optimizing performance and cost, I’ll be sharing insights drawn from experience and I’d love to hear yours too. Whether you're building from scratch, migrating legacy systems, or refining deployments, let’s talk about what actually works.59Views0likes1CommentComparision on Azure Cloud Sync and Traditional Entra connect Sync.
Introduction In the evolving landscape of identity management, organizations face a critical decision when integrating their on-premises Active Directory (AD) with Microsoft Entra ID (formerly Azure AD). Two primary tools are available for this synchronization: Traditional Entra Connect Sync (formerly Azure AD Connect) Azure Cloud Sync While both serve the same fundamental purpose, bridging on-prem AD with cloud identity, they differ significantly in architecture, capabilities, and ideal use cases. Architecture & Setup Entra Connect Sync is a heavyweight solution. It installs a full synchronization engine on a Windows Server, often backed by SQL Server. This setup gives administrators deep control over sync rules, attribute flows, and filtering. Azure Cloud Sync, on the other hand, is lightweight. It uses a cloud-managed agent installed on-premises, removing the need for SQL Server or complex infrastructure. The agent communicates with Microsoft Entra ID, and most configurations are handled in the cloud portal. For organizations with complex hybrid setups (e.g., Exchange hybrid, device management), is Cloud Sync too limited?410Views1like2CommentsFile restores failure from Azure VM Backup fail
We have several Azure VMs being backed up to a recovery vault. I am testing doing file restores from a VM just in case it is needed. I am using the procedure as outlined in the article https://learn.microsoft.com/en-us/azure/backup/backup-azure-restore-files-from-vm. All of the VMs are on a VNet in Azure, including the one I am running the restore from. The recovery services vault has a private endpoint on the VNet. When I run the generated script from an elevated command prompt, I get the general error "Exception caught while connecting to Target. Please retry after some time." I have tried several times over the week, so I don't think it is a transient issue. In looking at https://learn.microsoft.com/en-us/azure/backup/backup-azure-vm-file-recovery-troubleshoot#the-script-runs-but-the-connection-to-the-iscsi-target-failed under the heading "The script runs but the connection to the iSCSI target failed", I get back a response from the NSLookup with an external IP address. If I try to ping, I get no answer, which I expected since pings are usually blocked. I have made sure outbound port 3260 is not blocked. Does anyone have any suggestions? Eric LogsdonSolved533Views0likes4CommentsFormer Employer Abuse
My former employer, Albert Williams, president of American Security Force Inc., keeps adding my outlook accounts, computers and mobile devices to the company's azure cloud even though I left the company more than a year ago. What can I do to remove myself from his grip? Does Microsoft have a solution against abusive employers?64Views0likes0CommentsComo lograr una solución con un sistema multirregión de Azure
Si busca optimizar la disponibilidad de su aplicación web, no busque más allá de Microsoft Azure que ofrece una infinidad de servicios y herramientas que pueden ayudar a optimizar la disponibilidad de sus aplicaciones web, mejorando el rendimiento de estas y así reducir la latencia, lo que se traduce en una mejor experiencia del usuario. Entre ellas, FrontDoor, Traffic Manager, Application Gateway y Hybrid DNS, son algunas de las herramientas más potentes y versátiles que pueden utilizarse para garantizar que sus aplicaciones web estén siempre en funcionamiento con la máxima disponibilidad. Como bien lo mencionamos, encontramos a FrontDoor y Traffic Manager, son un servicio de gestión de tráfico global que se encarga de dirigir las solicitudes de los usuarios a los servidores más adecuados en función de diversos criterios como la ubicación geográfica, la carga del servidor o la latencia. Esto significa que, si un punto final se cae, el tráfico se redirigirá automáticamente a otro punto final, asegurando que su aplicación web permanezca disponible en todo momento, Traffic Manager puede configurarse para utilizar diversos métodos de enrutamiento, como round-robin, rendimiento y geográfico. Esta herramienta utiliza la ubicación del cliente para dirigir el tráfico al punto final más cercano y adicional puede detectar fallas en el servicio y redirigir el tráfico a servicios alternativos si es necesario. Contamos además con Application Gateway, que proporciona funciones avanzadas en su servicio al brindar balanceo de carga a nivel de aplicación, características de seguridad y escalabilidad para sus aplicaciones web. También proporciona Secure Sockets Layer (SSL) con funciones como la descarga del procedimiento de SSL, de sus servidores de aplicaciones, la afinidad de sesiones y el enrutamiento basado en URL. Application Gateway puede ayudar a configurar y a garantizar que el tráfico entrante se distribuya entre varias instancias de aplicaciones en diferentes regiones de Azure de forma que se maximice el rendimiento, la disponibilidad, escalabilidad y que pueden ayudar a su aplicación para satisfacer demandas cambiantes. Cuenta con la compatibilidad integrada con la autenticación de Azure Active Directory y WAF (Web Application Firewall), ya que puede estar tranquilo sabiendo que su aplicación web es segura y está disponible. Finalmente, esta herramienta nos ayuda con la prevención de ataques maliciosos y garantiza que solo los usuarios autorizados puedan acceder a las aplicaciones, y proporciona características avanzadas frente al equilibrio de carga y almacenamiento en caché de contenido que ayudan a optimizar el rendimiento y ayudar a reducir la latencia, brindando a los usuarios el mejor acceso posible al rendimiento. Otra opción que podemos brindar para nuestros clientes es aquella en donde pueden usar Azure para implementar una solución híbrida de Sistema de nombres de dominio (DNS), un enfoque que les permite integrar sin problemas sistemas locales con Azure y proporcionar una resolución de nombres de dominio uniforme en toda su infraestructura. Esto significa que puede utilizar los mismos nombres DNS tanto en las instalaciones como en la nube, lo que facilita la gestión de sus registros DNS y garantiza que su aplicación web esté siempre disponible y con funciones como la delegación de zonas y el reenvío condicional, puede personalizar su configuración DNS para satisfacer las necesidades únicas de su organización. Azure DNS Managed Service le permite configurar, administrar y monitorear registros DNS para los dominios de su organización, le brinda la flexibilidad de administrar los dominios de su organización desde las instalaciones y desde la nube. Puede usar Azure DNS para administrar zonas DNS públicas y Azure Private DNS para administrar zonas DNS privadas. Este enfoque permite a las organizaciones aprovechar la escalabilidad y la rentabilidad de los servicios de DNS en la nube mientras mantienen el control sobre su infraestructura de DNS local, con una solución DNS híbrida, puede garantizar una alta disponibilidad y escalabilidad de sus aplicaciones web multirregionales. Por último, también podemos elegir una aplicación web multirregional muy accesible que se desarrollará para proporcionar una solución de gestión de información robusta y fiable. Azure DNS Multirregión es una herramienta útil para empresas que buscan una solución de DNS escalable y altamente disponible, ya que es posible administrar y distribuir zonas DNS en múltiples regiones de Azure, lo que permite una mayor resiliencia y redundancia para la gestión de nombres de dominio. Una de las principales ventajas de Azure DNS Multirregión es su capacidad para administrar cada región como una sola colección de recursos, lo que brinda una mayor flexibilidad en la gestión y el control del entorno de DNS. El objetivo es hacer que la aplicación sea accesible desde cualquier parte del mundo, independientemente de la ubicación del usuario. Para lograrlo, se implementa una arquitectura de nube multirregión para alojar la aplicación, que permitirá a los usuarios conectarse a la aplicación desde cualquier parte del mundo, asegurando un alto nivel de seguridad y disponibilidad y acceso a su información más reciente. Por ejemplo, es posible redesplegar una región sin afectar el resto de la configuración, además, Azure DNS Multirregión se integra sin problemas con otras herramientas y servicios de Azure, como las VPN multisitio, lo que permite conectar redes virtuales y sitios locales en una topología que se adapta a las necesidades de la empresa. Los recursos de la nube se distribuirán en múltiples regiones geográficas, proporcionando una alta tolerancia a fallas, lo que significa que, si ocurre una falla en una región, las aplicaciones seguirán estando disponibles en otras regiones. Además, se introducirá tecnología de replicación de datos para garantizar la sincronización de datos entre regiones. En términos de seguridad, se implementará tecnología de encriptación de datos para brindar una capa adicional de seguridad para garantizar que solo los usuarios autorizados puedan acceder a la información. Así mismo se implementarán herramientas de monitoreo para detectar y corregir errores en tiempo real, lo que permitirá a los administradores de aplicaciones reaccionar y corregir errores antes de que afecten la disponibilidad de la aplicación. En resumen, Azure DNS Multirregión es una herramienta valiosa para empresas que buscan una solución de DNS escalable y altamente disponible, capaz de ofrecer redundancia y resiliencia en la gestión de nombres de dominio en múltiples regiones de Azure. Desafíos a los que nos enfrentamos Implementar el equilibrio de carga multirregional con FrontDoor, Traffic Manager y Application Gateway, una aplicación web multirregional de alta disponibilidad y Azure DNS Multirregión puede presentar algunos inconvenientes y desafíos. Para lo cual también presentamos algunas de las soluciones más significativas, y así tener en cuenta que para los posibles inconvenientes, podemos aplicar las soluciones adecuadas para superarlos. A continuación, se describen algunos de los posibles retos: Latencia: si los usuarios están distribuidos en diferentes regiones geográficas y el tráfico se redirige a una región distinta, puede haber un aumento en la latencia, lo que afectaría la experiencia del usuario. Dificultades en la configuración: La configuración de la arquitectura multirregional puede ser compleja, lo que puede aumentar la posibilidad de errores en la configuración y la implementación. Costos: La implementación de una arquitectura multirregional puede ser costosa en términos de infraestructura, mantenimiento y gestión de la red. Frente a estos desafíos, contamos con diversos recursos que nos permiten ver el valor agregado que estas herramientas brindan a su organización, dentro de las cuales cabe mencionar: Utilizar FrontDoor, Traffic Manager y Azure DNS Multirregión: FrontDoor es la nube moderna de Microsoft Content Delivery Network (CDN) que proporciona acceso rápido, confiable y seguro entre los usuarios y el contenido web estático y dinámico de las aplicaciones en todo el mundo, por otro lado el Traffic Manager permite dirigir el tráfico al punto de conexión más cercano al usuario en función de su ubicación geográfica. Por su parte, Azure DNS Multirregión proporciona una resolución de nombres de dominio rápida y global. Usar Application Gateway para balancear el tráfico: Application Gateway puede equilibrar el tráfico a nivel de la aplicación y optimizar la entrega de contenidos en función de la región de origen del usuario. Además, puede mejorar la seguridad mediante la aplicación de políticas de seguridad específicas. Utilizar políticas de ajuste de tráfico: Las políticas de ajuste de tráfico de Azure permiten gestionar el tráfico para asegurarse de que se redirija a la región más cercana al usuario. Esto ayuda a reducir la latencia y mejorar la experiencia del usuario. Automatizar la configuración: Es posible utilizar herramientas de automatización como Azure Resource Manager (ARM) o Azure PowerShell para automatizar la configuración y la implementación de la arquitectura multirregional. Utilizar herramientas de monitoreo: El monitoreo continuo de la infraestructura y las aplicaciones puede ayudar a identificar y resolver problemas en la arquitectura multirregional. Entonces, ¿Por qué elegir nuestras herramientas con Azure? Si entramos a resumir, podremos encontrar que el uso del equilibrio de carga multirregional con FrontDoor, Traffic Manager y Application Gateway, Aplicación web multirregional de alta disponibilidad y Azure DNS Multirregión ofrece varias ventajas, entre las que se incluyen: Alta disponibilidad: Al utilizar varias regiones, se puede garantizar que, si una región falla, el tráfico se dirija automáticamente a otra región activa, lo que reduce la posibilidad de interrupciones del servicio. Mejor rendimiento: Al utilizar el equilibrio de carga multirregional, los usuarios se conectan automáticamente al servidor más cercano a ellos geográficamente, lo que reduce la latencia y mejora el rendimiento. Escalabilidad: Al utilizar varias regiones, se puede aumentar la capacidad de la aplicación de manera fácil y rápida sin afectar la calidad del servicio. Reducción de costos: Al utilizar varias regiones, se pueden aprovechar los precios más bajos en las diferentes regiones de Azure, lo que reduce el costo total de la arquitectura. Seguridad: Al utilizar varias regiones, se puede garantizar que los datos estén disponibles en diferentes ubicaciones, lo que reduce el riesgo de pérdida de datos debido a un desastre natural o una falla en la región. Dada la diversidad de servicios, vemos que se pueden proporcionar a las empresas la escalabilidad, la disponibilidad y el rendimiento para mantener sus aplicaciones funcionando sin problemas y escalar hacia arriba o hacia abajo según sea necesario y al trabajar juntos podemos garantizar que sus operaciones comerciales sigan siendo eficientes y seguras. Con estas potentes herramientas a su disposición, puede asegurarse de que su aplicación web siga estando disponible y respondiendo pase lo que pase. ¿Por qué esperar? Comience a optimizar la disponibilidad de su aplicación web hoy mismo.1.1KViews0likes0CommentsConditional access policy or User risk policy set to force password at high risk doesnt work
Hi all, When setting Conditional access policy or User risk policy set to force password at high risk doesn't work instead I get a blocked windows on users. I have set SSPR too and I think this is a requirement What am I doing wrong?684Views0likes0CommentsAzure Site Recovery failback with VMware EFI Vms ?
Hello, I have a question about Azure Site Recovery (ASR) and I could not find an appropriate community and space, but if there is one, feel free to point me to it. I'm planning to deploy ASR for an on-premises environment with VMware machines running Windows. According to the https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-whats-new#updates-november-2019, ASR now supports VMware VMs with UEFI-based boot architecture. https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix#storage also indicates that UEFI (not Secure UEFI) is supported with Windows. Now if I look at https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-deployment-planner-analyze-report#incompatible-vms, I can read the following: Boot Type: Boot type of the VM. It can be either BIOS or EFI. Currently Azure Site Recovery supports Windows Server EFI VMs (Windows Server 2012, 2012 R2 and 2016) provided the number of partitions in the boot disk is less than 4 and boot sector size is 512 bytes. To protect EFI VMs, Azure Site Recovery mobility service version must be 9.13 or above. Only failover is supported for EFI VMs. Failback is not supported. Can someone confirm that ASR does not support failback for EFI VMs and therefore we need to convert BIOS from EFI to Legacy ? Thanks in advance NicolasSolved4.2KViews0likes2Comments