Introducing the VM Conversion tool in Windows Admin Center – Public Preview
As organizations update their infrastructure, a growing number are seeking adaptable, Microsoft-supported solutions that address current requirements while laying the path for future cloud and AI adoption. Azure provides an agile, scalable, cost-effective platform for infrastructure and innovation. Whether by modernizing to cloud technologies like Windows or Linux VMs, containers, Azure VMware Solution or PaaS services, Azure offers a world-class cloud experience. However, we recognize that some organizations must retain workloads on-premises due to data compliance, governance, or other regulatory requirements. For customers wanting to adopt Windows Server and Hyper-V for this use case, we are excited to provide a new option within Windows Admin Center, the VM Conversion tool, in public preview now. This agentless, cost-free tool streamlines the conversion of virtual machines from VMware to Windows Server with Hyper-V, providing customers flexibility with their on-premises virtualization environments while enabling a seamless transition path to Azure when desired. With minimal infrastructure requirements, the tool is particularly beneficial for small and medium-sized organizations. Additionally, with minimal setup time you can download the new VM Conversion tool extension in Windows Admin Center and begin converting virtual machines in under five minutes. Figure 1- VM Conversion tool in Windows Admin Center 🔑Key Features : Agentless, appliance-free discovery After establishing a connection to the virtualization environment, the tool conducts discovery of all virtual machines without requiring agents or appliances and does so in a non-intrusive manner. Minimal downtime The VM Conversion tool enables initial data replication while the source virtual machine remains operational, thereby preventing any interruptions to ongoing applications. After completing this initial replication, on user consent, the source VM is powered down so a subsequent replication pass can capture any data changes made during the first phase. This two-step process ensures that the cutover time from the source to the target VM is minimized. Group servers You can select and migrate up to 10 virtual machines at a time. This reduces manual effort and accelerates the transition to Windows Server. Boot configuration The tool automatically maps BIOS-based virtual machines to Generation 1 and UEFI-based machines to Generation 2, preserving boot configurations and ensuring compatibility. OS agnostic The tool supports conversion of both Linux and Windows guest OS VMs to Windows Server host. Multi-disk VM support Virtual machines that use several virtual hard disks—common in production environments—are fully supported. The operating system, data, and application disks all migrated together, so manual setup is not needed. ⚙️How It Works To ensure a smooth and reliable transition, the tool performs a comprehensive set of built-in prechecks. These checks validate critical VM attributes such as disk types, boot configuration (BIOS or UEFI), destination disk, memory requirements, and several more. By identifying potential issues early, administrators can proactively address them—minimizing the risk of migration failures and reducing downtime during the final cutover. The VM Conversion tool uses change block tracking (CBT) to efficiently replicate data from one virtual disk format to another. During the initial seeding phase, a full copy of the virtual machine is created while it remains online. This minimizes downtime and ensures data integrity. Before the final cutover, a delta replication captures all changes made since the initial copy, ensuring the destination VM is fully up-to-date post conversion to Hyper-V hosts. 🚀Ready to Take the Next Step? The VM Conversion tool is available now in the public feed of Windows Admin Center. You can install it directly from the Extensions settings in Windows Admin Center. To get started, ensure you're running the Windows Admin Center v2 GA release. 📘 For detailed setup instructions and prerequisites, refer to the Public Preview Documentation. 📍 Summary The VM Conversion tool offers a simple, supported path for organizations to streamline VM conversion to Hyper-V virtualization environments. With no added cost and minimal setup, it empowers customers to streamline VM migration and prepare for the cloud at their own pace. Support for Azure Arc-enabled servers is also planned for future releases, further enhancing hybrid management capabilities. We’re continuously evolving the VM Conversion tool based on user feedback. Please continue to share your feedback here and help us prioritize our efforts for future releases. Happy converting!Migrate upgraded ADFS farm from WID to SQL
Hi, We have a few ADFS farms that have been upgraded/migrated from ADFS v3 to ADFS v4 in the past. We now want to migrated the WID database to SQL Always-On. There are numerous articles describing the migration from WID to SQL, but they all only mention AdfsConfiguration.mdf, but in an upgraded farm you also have a AdfsConfigurationV3.mdf (and its respective ldf). Can we ignore the V3 files or do we need to migrate them to? Please advise! Kind regards, Enrico Klein
Windows event collector (WEC) troubles
Hi all. I have really frustrating issue I can`t resolve. We have set up WEC, a long time ago... Now I upgraded in-place to server 2025 and it`s behaving really weird. Problem is this: I created new subscription and my PC was sending events just fine yesterday. I rebooted server and my PC, still all is fine. Turned off my PC, went to sleep, started working in the morning and NO logs from my machine in WEC. At all. Other PCs also randomy sending logs some yes some no. So I tested WinRM connectivity all fine. Error on my PC: The forwarder is having a problem communicating with subscription manager at address http://MYWECSERVER:5985/wsman/SubscriptionManager/WEC. Error code is 2150859263 and Error Message is <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859263" Machine="MYWECSERVER"><f:Message> <f:ProviderFault provider="Subscription Manager Provider" path="%systemroot%\system32\WsmSvc.dll"> <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859263" Machine="MYWECSERVER"> <f:Message>The event source of the push subscription is in disable or inactive on the Event controller server. </f:Message></f:WSManFault></f:ProviderFault></f:Message></f:WSManFault>. I have also some errors on WEC server: The Subscription DomainComputers could not be activated on target machine MY-PERSONAL-PC due to communication error. Error Code is 0. All retries have been performed before reaching this point and so the subscription will remain inactive on this target until subscription is resubmitted / reset. Additional fault message: eventsource is in either disable or inactive state OR The Subscription DomainComputers could not be activated on target machine MY-PERSONAL-PC due to communication error. Error Code is 20. All retries have been performed before reaching this point and so the subscription will remain inactive on this target until subscription is resubmitted / reset. Additional fault message: eventsource is in either disable or inactive state Also runtime status is like this: A lot of Active computers, mine is in yellow Inactive state... I have NO idea how to fix this, and why it works for some clients and not for others and most perplexing question, why it worked yesterday until sleep. Just like that WEC sets status to Inactive and then my PC sends logs and does not change status back to Active. Thanks for all suggestions!Requesting and Installing an SSL Certificate for Internet Information Server (IIS)
Generate a Certificate Signing Request (CSR) Generate the request using the Certificates snap-in in Microsoft Management Console (MMC). Step 1: Open the Certificates Snap-In Press Windows + R, type mmc, and press Enter. Go to File > Add/Remove Snap-in. Select Certificates and click Add. Choose Computer account, then click Next. Select Local computer and click Finish. Click OK to close the Add/Remove window. Step 2: Start the CSR Wizard In the left pane, expand Certificates (Local Computer). Right-click Personal and select: All Tasks → Advanced Operations → Create Custom Request Step 3: Configure the Request On the Certificate Enrollment page, click Next. Select Proceed without enrollment policy and click Next. On the “Certificate Information” page, expand Details and click Properties. On the General tab: Enter a friendly name, e.g., WS25-IIS Certificate. On the Subject tab: Under Subject name, choose Common Name. Enter the fully qualified domain name (FQDN), e.g. ws25-iis.windowserver.info. Click Add. Under Alternative name, choose DNS. Enter the same FQDN and click Add. On the Extensions tab: Under Key Usage, ensure Digital Signature and Key Encipherment are selected. Under Extended Key Usage, add Server Authentication. On the Private Key tab: Under Cryptographic Provider, select RSA, Microsoft Software Key Storage Provider. Set Key size to 2048 bits. Check Make private key exportable and Allow private key to be archived. Click Apply, then OK, and then Next. Step 4: Save the Request Choose a location to save the request file (e.g. C:\Temp). Ensure the format is set to Base 64. Provide a filename such as SSLRequest.req. Click Finish. You can open the file in Notepad to verify the Base64-encoded request text. Submit the CSR to a Certification Authority You can use an internal Windows CA or a public CA. The example below assumes a web enrollment interface. Step 1: Open the CA Web Enrollment Page Navigate to your CA’s enrollment site. If the server does not trust the CA, you may receive a warning. You'll need to or install the CA certificate as needed. Step 2: Submit an Advanced Certificate Request Select Request a certificate. Choose advanced certificate request. Open the CSR in Notepad, copy the Base64 text, and paste it into the request form. Click Submit. Step 3: Approve the Request (if required) If your CA requires approval, sign in to the CA server and approve the pending request. Step 4: Download the Issued Certificate Return to the CA web enrollment page. View the status of pending requests. Locate your request and select it. Choose the Base 64 encoded certificate format. Download the certificate. Save it to a known location and rename it meaningfully (e.g. WS25-IIS-Cert.cer). Install the SSL Certificate Double-click the .cer file to open it. Click Install Certificate. Choose Local Machine as the store location. When prompted for the store, select: Place all certificates in the following store Choose Personal Click Next, then Finish. Confirm the success message by clicking OK. The certificate is now imported and available for use by IIS. Bind the Certificate in IIS Step 1: Open IIS Manager Open Server Manager or search for IIS Manager. In the left pane, expand the server and select your website (e.g., Default Web Site). Step 2: Add an HTTPS Binding In the Actions pane, click Bindings. In the Site Bindings window, click Add. Select: Type: https Hostname: the FQDN used in the certificate (e.g., ws25-iis.windowserver.info) SSL Certificate: choose the certificate you installed (e.g. WS25-IIS Certificate) Click OK, then Close. Test the HTTPS Connection Open Microsoft Edge (or your preferred browser). Browse to the site using https:// and the FQDN. Example: https://ws25-iis.windowserver.info Confirm you see the IIS default page (or your site’s content). Click the padlock in the address bar: Verify the certificate is valid. Check the certificate details if desired. If the page loads securely without warnings, the certificate is installed and bound correctly.
Strengthening 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! Pierre
Noob needs help with RDP Services
I am new to Windows server management. I setup a 2019 Server in a VM (Hyper-V). I installed the licenses we got for RDP from MS after installing the Remote Desktop Services. I am getting an error about Remote Desktop Licensing Mode is not configured. Tells me to use Server Manger to specify RD Connection Broker. Either I neglected to install it or configure it, not sure. Articles I find say go to Server Manager -> Remote Desktop Services -> Overview... BUT, that tells me I am logged in with a local account but must use a domain account to manage servers and collections. Again, not using a DC. This server is not part of a domain. We do not run AD internally only AzureAD online. We have 1 program we still run internally and users RDP to it. Should I remove the service and reinstall? What about the licenses I added already? How to I keep them? Any assistance will be greatly appreciated... J
LDAPS and Certificate Creation
Hi, I've been asked to setup secure LDAP and convert all of our LDAP services to LDAPS. Something totally new to me, so I've been trying to teach myself. One issue I've run into is I'm not finding much information on how to create the secure certificates, so I'm looking for guidance. An ex-colleague stood up a certificate authority server (CA) and an intermediate certificate authority server (IA). Currently, the CA is powered down, which seems to be a best practice. The IA server is up and running, however, when I go to my domain controller (DC) and look at the Local Computer\Personal\Certificates section I do see a certificate, but it was issued by the CA and expired last summer. Shouldn't that certificate have been issued by the IA? How do I go about issuing certificates for this and other purposes, like all of the web-based control systems in my network like vCenter that complain about not being secure when I log into them? I've been searching for tutorials on the subject but only seem to find tutorials on how to install it, not how to use certsrv to issue and renew certificates. Does anyone know of any tutorials or walk-throughs like this? Thanks in advance!
Hyper-V: How do VMs communicate with external?
Simple scenario: VM --> vNIC --> vSwitch (external) --> physNIC --> physSwitch The vNIC assigned to the VM has MAC address aa:aa:aa:aa:aa:aa, the physical NIC (physNIC; the vSwitch of type external is connected to it) has bb:bb:bb:bb:bb:bb. What mechanism ensures that when the VM sends a network packet to the external network (the physical network connected to the physical switch physSwitch), the MAC address of its vNIC (aa:aa:aa:aa:aa:aa) is used, and not the MAC address of the physNIC (bb:bb:bb:bb:bb:bb)? In other words: what makes physSwitch "see" aa:aa:aa:aa:aa:aa when the VM communicates to an external endpoint?ISO version reporting
Is there a standard way in which the Windows installer ISOs can be interrogated for which version of Windows is on them? This is a bit convoluted so I'll explain the use case. When installing W10 on one of the last generation of x64 Apple Macs, the Boot Camp installer will take the ISO and prepare it by injecting drivers - particularly that for the T2 security chip which handles the first part of the boot process and is the storage controller, among other things. With W10 going out of support (and W11 not really an option due to the hardware requirements) I have been looking at trying to install one ofthe W10-based server versions instead. These are obviously very similar in structure and would probably install and work from a technical standpoint - but if I try it the Boot Camp installer reports that the ISOs aren't Windows 10, and won't proceed. I'm basically looking to clarify whether there is any minor editing of the ISO (or files on it) which can be done to convince Boot Camp that actually this is W10. Anyone know? Thanks
