pierre roman
100 TopicsStrengthening Azure File Sync security with Managed Identities
Hello Folks, As IT pros, we’re always looking for ways to reduce complexity and improve security in our infrastructure. One area that’s often overlooked is how our services authenticate with each other. Especially when it comes to Azure File Sync. In this post, I’ll walk you through how Managed Identities can simplify and secure your Azure File Sync deployments, based on my recent conversation with Grace Kim, Program Manager on the Azure Files and File Sync team. Why Managed Identities Matter Traditionally, Azure File Sync servers authenticate to the Storage Sync service using server certificates or shared access keys. While functional, these methods introduce operational overhead and potential security risks. Certificates expire, keys get misplaced, and rotating credentials can be a pain. Managed Identities solve this by allowing your server to authenticate securely without storing or managing credentials. Once enabled, the server uses its identity to access Azure resources, and permissions are managed through Azure Role-Based Access Control (RBAC). Using Azure File Sync with Managed Identities provides significant security enhancements and simpler credential management for enterprises. Instead of relying on storage account keys or SAS tokens, Azure File Sync authenticates using a system-assigned Managed Identity from Microsoft Entra ID (Azure AD). This keyless approach greatly improves security by removing long-lived secrets and reducing the attack surface. Access can be controlled via fine-grained Azure role-based access control (RBAC) rather than a broadly privileged key, enforcing least-privileged permissions on file shares. I believe that Azure AD RBAC is far more secure than managing storage account keys or SAS credentials. The result is a secure-by-default setup that minimizes the risk of credential leaks while streamlining authentication management. Managed Identities also improve integration with other Azure services and support enterprise-scale deployments. Because authentication is unified under Azure AD, Azure File Sync’s components (the Storage Sync Service and each registered server) seamlessly obtain tokens to access Azure Files and the sync service without any embedded secrets. This design fits into common Azure security frameworks and encourages consistent identity and access policies across services. In practice, the File Sync managed identity can be granted appropriate Azure roles to interact with related services (for example, allowing Azure Backup or Azure Monitor to access file share data) without sharing separate credentials. At scale, organizations benefit from easier administration. New servers can be onboarded by simply enabling a managed identity (on an Azure VM or an Azure Arc–connected server) and assigning the proper role, avoiding complex key management for each endpoint. Azure’s logging and monitoring tools also recognize these identities, so actions taken by Azure File Sync are transparently auditable in Azure AD activity logs and storage access logs. Given these advantages, new Azure File Sync deployments now enable Managed Identity by default, underscoring a shift toward identity-based security as the standard practice for enterprise file synchronization. This approach ensures that large, distributed file sync environments remain secure, manageable, and well-integrated with the rest of the Azure ecosystem. How It Works When you enable Managed Identity on your Azure VM or Arc-enabled server, Azure automatically provisions an identity for that server. This identity is then used by the Storage Sync service to authenticate and communicate securely. Here’s what happens under the hood: The server receives a system-assigned Managed Identity. Azure File Sync uses this identity to access the storage account. No certificates or access keys are required. Permissions are controlled via RBAC, allowing fine-grained access control. Enabling Managed Identity: Two Scenarios Azure VM If your server is an Azure VM: Go to the VM settings in the Azure portal. Enable System Assigned Managed Identity. Install Azure File Sync. Register the server with the Storage Sync service. Enable Managed Identity in the Storage Sync blade. Once enabled, Azure handles the identity provisioning and permissions setup in the background. Non-Azure VM (Arc-enabled) If your server is on-prem or in another cloud: First, make the server Arc-enabled. Enable System Assigned Managed Identity via Azure Arc. Follow the same steps as above to install and register Azure File Sync. This approach brings parity to hybrid environments, allowing you to use Managed Identities even outside Azure. Next Steps If you’re managing Azure File Sync in your environment, I highly recommend transitioning to Managed Identities. It’s a cleaner, more secure approach that aligns with modern identity practices. ✅ Resources 📚 https://learn.microsoft.com/azure/storage/files/storage-sync-files-planning 🔐 https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview ⚙️ https://learn.microsoft.com/azure/azure-arc/servers/overview 🎯 https://learn.microsoft.com/azure/role-based-access-control/overview 🛠️ Action Items Audit your current Azure File Sync deployments. Identify servers using certificates or access keys. Enable Managed Identity on eligible servers. Use RBAC to assign appropriate permissions. Let me know how your transition to Managed Identities goes. If you run into any snags or have questions, drop a comment. Cheers! Pierre122Views0likes0CommentsSupercharging NVAs in Azure with Accelerated Connections
Hello folks, If you run firewalls, routers, or SD‑WAN NVAs in Azure and your pain is connection scale rather than raw Mbps, there is a feature you should look at: Accelerated Connections. It shifts connection processing to dedicated hardware in the Azure fleet and lets you size connection capacity per NIC, which translates into higher connections‑per‑second and more total active sessions for your virtual appliances and VMs. This article distills a recent E2E chat I hosted with the Technical Product Manager working on Accelerated Connections and shows you how to enable and operate it safely in production. The demo and guidance below are based on that conversation and the current public documentation. What Accelerated Connections is (and what it is not) Accelerated Connections is configured at the NIC level of your NVAs or VMs. You can choose which NICs participate. That means you might enable it only on your high‑throughput ingress and egress NICs and leave the management NIC alone. It improves two things that matter to infrastructure workloads: Connections per second (CPS). New flows are established much faster. Total active connections. Each NIC can hold far more simultaneous sessions before you hit limits. It does not increase your nominal throughput number. The benefit is stability under high connection pressure, which helps reduce drops and flapping during surges. There is a small latency bump because you introduce another “bump in the wire,” but in application terms it is typically negligible compared to the stability you gain. How it works under the hood In the traditional path, host CPUs evaluate SDN policies for flows that traverse your virtual network. That becomes a bottleneck for connection scale. Accelerated Connections offloads that policy work onto specialized data processing hardware in the Azure fleet so your NVAs and VMs are not capped by host CPU and flow‑table memory constraints. Industry partners have described this as decoupling the SDN stack from the server and shifting the fast‑path onto DPUs residing in purpose‑built appliances, delivered to you as a capability you attach at the vNIC. The result is much higher CPS and active connection scale for virtual firewalls, load balancers, and switches. Sizing the feature per NIC with Auxiliary SKUs You pick a performance tier per NIC using Auxiliary SKU values. Today the tiers are A1, A2, A4, and A8. These map to increasing capacity for total simultaneous connections and CPS, so you can right‑size cost and performance to the NIC’s role. As discussed in my chat with Yusef, the mnemonic is simple: A1 ≈ 1 million connections, A2 ≈ 2 million, A4 ≈ 4 million, A8 ≈ 8 million per NIC, along with increasing CPS ceilings. Choose the smallest tier that clears your peak, then monitor and adjust. Pricing is per hour for the auxiliary capability. Tip: Start with A1 or A2 on ingress and egress NICs of your NVAs, observe CPS and active session counters during peak events, then scale up only if needed. Where to enable it You can enable Accelerated Connections through the Azure portal, CLI, PowerShell, Terraform, or templates. The setting is applied on the network interface. In the portal, export the NIC’s template and you will see two properties you care about: auxiliaryMode and auxiliarySku. Set auxiliaryMode to AcceleratedConnections and choose an auxiliarySku tier (A1, A2, A4, A8). Note: Accelerated Connections is currently a limited GA capability. You may need to sign up before you can configure it in your subscription. Enablement and change windows Standalone VMs. You can enable Accelerated Connections with a stop then start of the VM after updating the NIC properties. Plan a short outage. Virtual Machine Scale Sets. As of now, moving existing scale sets onto Accelerated Connections requires re‑deployment. Parity with the standalone flow is planned, but do not bank on it for current rollouts. Changing SKUs later. Moving from A1 to A2 or similar also implies a downtime window. Treat it as an in‑place maintenance event. Operationally, approach this iteratively. Update a lower‑traffic region first, validate, then roll out broadly. Use active‑active NVAs behind a load balancer so one instance can drain while you update the other. Operating guidance for IT Pros Pick the right NICs. Do not enable on the management NIC. Focus on the interfaces carrying high connection volume. Baseline and monitor. Before enabling, capture CPS and active session metrics from your NVAs. After enabling, verify reductions in connection drops at peak. The point is stability under pressure. Capacity planning. Start at A1 or A2. Move up only if you see sustained saturation at peak. The tiers are designed so you do not pay for headroom you do not need. Expect a tiny latency increase. There is another hop in the path. In real application flows the benefit in fewer drops and higher CPS outweighs the added microseconds. Validate with your own A/B tests. Plan change windows. Enabling on existing VMs and resizing the Auxiliary SKU both involve downtime. Use active‑active pairs behind a load balancer and drain one side while you flip the other Why this matters Customers in regulated and high‑traffic industries like health care often found that connection scale forced them to horizontally expand NVAs, which inflated both cloud spend and licensing, and complicated operations. Offloading the SDN policy work to dedicated hardware allows you to process many more connections on fewer instances, and to do so more predictably. Resources Azure Accelerated Networking overview: https://learn.microsoft.com/azure/virtual-network/accelerated-networking-overview Accelerated connections on NVAs or other VMs (Limited GA): https://learn.microsoft.com/azure/networking/nva-accelerated-connections Manage accelerated networking for Azure Virtual Machines: https://learn.microsoft.com/azure/virtual-network/manage-accelerated-networking Network optimized virtual machine connection acceleration (Preview): https://learn.microsoft.com/azure/virtual-network/network-optimized-vm-network-connection-acceleration Create an Azure Virtual Machine with Accelerated Networking: https://docs.azure.cn/virtual-network/create-virtual-machine-accelerated-networking Next steps Validate eligibility. Confirm your subscription is enabled for Accelerated Connections and that your target regions and VM families are supported. Learn article Select candidate workloads. Prioritize NVAs or VMs that hit CPS or flow‑table limits at peak. Use existing telemetry to pick the first region and appliance pair. 31 Pilot on one NIC per appliance. Enable on the data‑path NIC, start with A1 or A2, then stop/start the VM during a short maintenance window. Measure before and after. 32 Roll out iteratively. Expand to additional regions and appliances using active‑active patterns behind a load balancer to minimize downtime. 33 Right‑size the SKU. If you observe sustained headroom, stay put. If you approach limits, step up a tier during a planned window. 34140Views0likes0CommentsAzure File Sync: A Practical, Tested Deployment Playbook for ITPros.
This post distills that 10‑minute drill into a step‑by‑step, battle‑tested playbook you can run in your own environment, complete with the “gotchas” that trip folks up, why they happen, and how to avoid them. But first... Why Use Azure File Sync? Hybrid File Services: Cloud Meets On-Prem Azure File Sync lets you centralize your organization’s file shares in Azure Files while keeping the flexibility, performance, and compatibility of your existing Windows file servers. You can keep a full copy of your data locally or use your Windows Server as a fast cache for your Azure file share. This means you get cloud scalability and resilience, but users still enjoy local performance and familiar protocols (SMB, NFS, FTPS). Cloud Tiering: Optimize Storage Costs With cloud tiering, your most frequently accessed files are cached locally, while less-used files are tiered to the cloud. You control how much disk space is used for caching, and tiered files can be recalled on-demand. This enables you to reduce on-prem storage costs without sacrificing user experience. Multi-Site Sync: Global Collaboration Azure File Sync is ideal for distributed organizations. You can provision local Windows Servers in each office, and changes made in one location automatically sync to all others. This simplifies file management and enables faster access for cloud-based apps and services. Business Continuity and Disaster Recovery Azure Files provides resilient, redundant storage, so your local server becomes a disposable cache. If a server fails, you simply add a new server to your Azure File Sync deployment, install the agent, and sync. Your file namespace is downloaded first, so users can get back to work quickly. You can also use warm standby servers or Windows Clustering for even faster recovery. Cloud-Side Backup Note: Azure File Sync is NOT a backup solution.... But, you ca reduce on-prem backup costs by taking centralized backups in the cloud using Azure Backup. Azure file shares have native snapshot capabilities, and Azure Backup can automate scheduling and retention. Restores to the cloud are automatically downloaded to your Windows Servers. Seamless Migration Azure File Sync enables seamless migration of on-prem file data to Azure Files. You can sync existing file servers with Azure Files in the background, moving data without disrupting users or changing access patterns. File structure and permissions remain intact, and apps continue to work as expected. Performance, Security, and Compatibility Recent improvements have boosted Azure File Sync’s performance (up to 200 items/sec), and it now supports Windows Server 2025 and integrates with Windows Admin Center for unified management. Managed identities and Active Directory-based authentication are supported for secure, keyless access. Real-World Use Cases Branch Office Consolidation: Multiple sites, each with its own file server, can be consolidated into a central Azure File Share while maintaining local performance. Business Continuity: Companies facing threats like natural disasters use Azure File Sync to improve server recovery times and ensure uninterrupted work. Collaboration: Organizations leverage Azure File Sync for fast, secure collaboration across locations, reducing latency and simplifying IT management. The Quick Troubleshooting TL;DR Insufficient permissions during cloud endpoint creation → “Role assignment creation failed.” You need Owner or the Azure File Sync Administrator built‑in role; Contributor isn’t enough because the workflow must create role assignments. Region mismatches → Your file share and Storage Sync Service must live in the same region as the deployment target. Wrong identity/account → If you’re signed into the wrong tenant or account mid‑portal (easy to do), the wizard fails when it tries to create the cloud endpoint. Switch to the account that actually has the required role and retry. Agent/version issues → An old agent on your Windows Server will cause registration or enumeration problems. Use the latest agent and consider auto‑upgrade to stay current. Networking & access keys → Ensure access keys are enabled on the storage account and required outbound URLs/ports are allowed. Operational expectations → Azure File Sync runs on a roughly 24‑hour change detection cycle by default; for DR drills or immediate needs, trigger change detection via PowerShell. And remember: File Sync is not a backup. Back up the storage account. End‑to‑End Deployment Playbook 1) Prerequisites (don’t skip these) Storage account supporting SMB 3.1.1 (and required authentication settings), with access keys enabled. Create your Azure file share in the same region as your File Sync deployment. Establish a clear naming convention Windows Server for the File Sync agent (example: Windows Server 2019) Identity & Access: Assign either Owner or Azure File Sync Administrator (a least‑privilege built‑in role designed specifically for this scenario). Contributor will let you get partway (storage account, Storage Sync Service) but will fail when creating the cloud endpoint because it can’t create role assignments. 2) Lay down the cloud side In the Azure portal, create the file share in your chosen storage account/region. Create a Storage Sync Service (ideally in a dedicated resource group), again ensuring the region is correct and supported for your needs. 3) Prep the server On your Windows Server, install the Azure File Sync agent (latest version). During setup, consider enabling auto‑upgrade; if the server is down during a scheduled upgrade, it catches up on the next boot, keeping you current with security and bug fixes. Register the server to your Storage Sync Service (select subscription, resource group, and service). If you have multiple subscriptions, the portal can occasionally hide one, PowerShell is an alternative path if needed. 4) Create the sync topology In the Storage Sync Service, create a Sync Group. This is the container for both cloud and server endpoints. Under normal conditions, the cloud endpoint is created automatically when you select the storage account + file share. If you hit “role assignment creation failed” here, verify your signed‑in account and role. Switching back to the account with the proper role resolves it; you can then recreate the cloud endpoint inside the existing Sync Group. Add a server endpoint: pick the registered server (it must show up in the drop‑down, if it doesn’t, registration isn’t complete) and the local path to sync. 5) Cloud tiering & initial sync behavior Cloud tiering keeps hot data locally and stubs colder data to conserve space. If you disable cloud tiering, you’ll maintain a full local copy of all files. If enabled, set the Volume Free Space Policy (how much free space to preserve on the volume) and review recall policy implications. Choose the initial sync mode, merge existing content or overwrite. 6) Ops, monitoring, and DR notes Change detection cadence is approximately 24 hours. For DR tests or urgent cutovers, run the change detection PowerShell command to accelerate discovery of changes. Backups: Azure File Sync is not a backup. Protect your storage account using your standard backup strategy. Networking: Allow required outbound ports/URLs; validate corporate proxies/firewalls. Monitoring: Turn on the logging and monitoring you need for telemetry and auditing. 7) Performance & cost planning Evaluate Provisioned v2 storage accounts to dial in IOPS/throughput to your business needs and gain better pricing predictability. It’s a smart time to decide this up front during a new deployment. 8) Identity options & least privilege You can also set up managed identities for File Sync to reduce reliance on user principals. If you do use user accounts, ensure they carry the Azure File Sync Administrator role or Owner. Keep the agent updated; it’s basic hygiene that prevents a surprising number of issues. 9) Quotas & capacity troubleshooting Hitting quota problems? Revisit your Volume Free Space Policy (cloud tiering) and recall policy. Sometimes the answer is simply adding a disk or increasing its size as data patterns evolve. Key Benefits for Infra Teams Hybrid file services without forklift: Keep your existing Windows file servers while centralizing data in Azure Files, adding elasticity and resiliency with minimal disruption . Right‑sized capacity on‑prem: Cloud tiering preserves local performance for hot data and trims cold data footprint to stretch on‑prem storage further. Operational predictability: Built‑in auto‑upgrade for the agent and a known change detection cycle, with the ability to force change detection for DR/failover testing. Least‑privilege by design: The Azure File Sync Administrator role gives just the rights needed to deploy/manage sync without over‑provisioning. Performance on your terms: Option to choose Provisioned v2 to meet IOPS/throughput targets and bring cost clarity. Available Resources What is Azure File Sync?: https://learn.microsoft.com/azure/storage/file-sync/file-sync-introduction Azure Files: More performance, more control, more value for your file data: https://azure.microsoft.com/blog/azure-files-more-performance-more-control-more-value-for-your-file-data/ Azure File Sync Deployment Guide: https://learn.microsoft.com/azure/storage/file-sync/file-sync-deployment-guide Troubleshooting documentation : https://learn.microsoft.com/troubleshoot/azure/azure-storage/files/file-sync/file-sync-troubleshoot Azure File Sync “copilot” troubleshooting experience: https://learn.microsoft.com/azure/copilot/improve-storage-accounts Next Steps (Run This in Your Lab) Verify roles: On the target subscription/resource group, grant Azure File Sync Administrator (or Owner) to your deployment identity. Confirm in Access control (IAM). Create the file share in the same region as your Storage Sync Service. Enable access keys on the storage account. Install the latest agent on your Windows Server; enable auto‑upgrade. Register the server to your Storage Sync Service. Create a Sync Group, then the cloud endpoint. If you see a role assignment error, re‑check your signed‑in account/role and retry. Add the server endpoint with the right path, decide on cloud tiering, set Volume Free Space Policy, and choose initial sync behavior (merge vs overwrite). Open required egress on your network devices, enable monitoring/logging, and plan backup for the storage account. Optionally evaluate Provisioned v2 for throughput/IOPS and predictable pricing before moving to production. If you’ve got a scenario that behaves differently in the field, I want to hear about it. Drop me a note with what you tried, what failed, and where in the flow it happened. Cheers! Pierre330Views0likes0CommentsWSL2 now available on Windows Server 2022
Hello folks! If you’re one of those Devs/ITPros using the Windows Subsystem for Linux (WSL) you know how useful and powerful it can be. We announced during Microsoft Build last week that WSL2 will be broadly available in June. But I could not wait. Here’s how I installed it. It’s pretty simple. Check it out!74KViews5likes5CommentsSetting up DNS in a Hybrid Environment.
Hello Folks, I’m not sure when this became a series, but it’s looking like it’s going to be ongoing. I’m hoping it can give the community a sense of how you can slowly adopt cloud services to enhance your on-prem environment. It started a few weeks ago with the post on how I needed to replace the edge device on my home network. Then I followed up with how I now can use the site-to-site VPN I set up to access (RDP & SSH) all the servers in my environment using the Bastion host on Azure. But I’m at a point where I’ve got demo servers and services on both sides of the VPN. Name resolution is fast becoming an issue. How do I set up a DNS structure to efficiently resolve server IP addresses from an on-premises environment and vice versa without deploying VM-based DNS servers.19KViews5likes4CommentsMicrosoft Copilot in Azure Series - Data Collection and Feedback
Hello folks! Today, we're continuing our coverage of Microsoft Copilot in Azure. We’ll talk about how to provide feedback and because we've been getting this question multiple times, what data is collected by Microsoft Copilot in Azure. So, buckle up and let's get started!3.4KViews0likes0CommentsWhat are the Differences Between Azure Active Directory and Azure Active Directory Domain Services?
If you are moving, building, or subscribing to apps in Azure, you need to understand which flavour of AD to use. Azure Active Directory (AAD) Azure Active Directory Domain Services (AADDS) Active Directory (AD) Let's discuss the differences.167KViews20likes14CommentsMicrosoft Copilot in Azure Series - Copilot Access Management
Hello folks! Today, we’re diving into Microsoft Copilot in Azure. It’s like having a super-smart assistant in the cloud! It’s an AI-powered tool that’s all about making your life easier when you’re working with Azure, when you’re navigating the Azure portal, or using the Azure mobile app. And today we'll cover how to manage access to it.4.4KViews0likes2CommentsBuilding a Policy to deploy the new Azure monitor Agent.
Hello folks, Following my recording with Shayoni Seth (Senior Program Manager on the Azure Monitor Agent team) regarding the use and deployment of the upcoming Azure Monitor Agent (AMA) currently in preview. We established that there are 2 key parts of the new agent: The Data Collection Rule The Agent deployment. So, if you are testing this new Azure Monitor Agent and you want to avoid having to deploy the agent to each new VM individually in the portal, you can create an Azure Policy. let's see what's involved.22KViews3likes10Comments