Demoting DC Windows Server 2019
Windows Server 2019 with Domain controller forest version 2016. When demoting our Domain controller XYDC01 in Site XY, it is the only DC and DNS in the site, but all other 20 sites have a DC with DNS. We get this error when demoting our DC. Active Directory domain controller appears to be the last DNS server for the following Active Directory-integrated zones: enterpriseregistration.jens.be If you demote this domain controller, you may be unable to resolve any DNS names in these zones. If you wish to proceed, specify the 'IgnoreLastDNSServerForZone' option. I have tested: #other DC and DNS server in other site Resolve-DnsName enterpriseregistration.jens.be -Server XXDC02 Test-NetConnection XXDC02-Port 135 Test-NetConnection XXDC02-Port 53 Get-DnsServerZone -Name "enterpriseregistration.jens.be" repadmin /syncall /AdeP All test have passed and succesfull. Replication scope = Forest Other DCs have DNS role Zone contains NS records for other DCs Zone exists on other DCs But still having the same issue when trying to demote
Deploying Multiple NPS Servers
I have been working on ditching our password-based WiFi with WPA2-Enterprise. On DC1 I deployed internal CA, NPS, and group policies that auto-request certs and deploy wireless network settings. Cisco AP is pointed to DC1 as the radius server. NPS has been registered in AD and wireless network policy has been created. Test laptops get their cert and connect just fine. It's working. For redundancy, I installed NPS on DC2. This NPS instance has also been registered in AD, and I imported the NPS config from DC1 to DC2 NPS. Cisco AP has DC1 as first radius server and DC2 as second radius server. If I stop NPS on DC1 to force the Cisco AP to authenticate against DC2, test laptops won't authenticate and connect. What am I missing? They're configured exactly the same (except DC1 hosts the CA...I was under the assumption the CA is AD integrated).
Advice for replacing a Windows 2012R2 file server
We have a small company network that includes one Windows Server 2012R2 file server necessary to run Sequel for two server hosted business applications, file and print services for the user accounts and is also the Domain Controller for the Active Directory local forest and domain. Six Windows 11 Pro workstations are domain attached to the file server. The workstations all have a local user account and after domain attaching to the file server, a user.Acme user account with Administrator rights to their local computer. Each has its own 192.168.1.x static address and uses their domain user account with mapped drives to access the fileserver. The existing file server name is ACMEWS2012R2, local public static ip 192.168.1.12, DNS Domain Acme.LAN, Netbios name ACME, local accounts are located in \Users\username, and runs SQL Server Express 2012 with default MSSQL database name and mixed security using the SA with password credentials. The new file server will be using Windows Server 2022 (the company apps are not yet certified for 2025) and SQL SVR Express 2022 and I am looking for information about what configuration decisions I can make to hopefully minimize the need to install new user accounts on the workstations, copy all the user folders between users accounts and reinstall applications. My understanding of Domain security is limited, knowing just enough to get workstations attached and properly accessing the file server SQL based applications. My Google results have provided some piecemeal answers, but I would like to better understand the big picture before starting the server upgrade and make some irreversible configuration choices that would cause unnecessary work re-attaching the workstations. I would first ask for recommendations whether and why to keep or change each of the following: The file server machine name The file server 192.168.1.12 IP address The file server Administrator account and password. The Acme.LAN forest and root domain name that was defined after adding the Active Directory Domain Service role that also added File and Print Services and Group Policy Management. The SQL Server Express default MSSQL database name The SQL Server Express SA account name and password I would also ask about the best steps for disconnecting workstations from the old domain then joining the new domain to hopefully retain the existing workstation user account, or if not, to minimize the need to copy users folders between the user accounts and / or uninstall then reinstall the workstation applications to properly authenticate to the new user account. I would greatly appreciate some experienced insights for how to best accomplish these upgrade goals. Thanks, all!
Unable to manage DFS namespace
(updated post) Hi, We have an issue with DFS at our site. It has been working fine for years, but recently the ability to manage it using the DFS MMC no longer works. DFS is still working for the users fine and we can map to it manually, but the MMC tool no longer connects. We can create and manage new namespaces fine though. The error is: " The namespace cannot be queried. The specified domain either does not exist or could not be contacted. " We can't risk recreating the namespace due to the impact on users, so anyone have any idea to fix this and get DFS MMC working to allow management of the namespace? Many thanks DBAdvice for replacing a Windows 2012R2 file server
We have a small company network that includes one Windows Server 2012R2 file server necessary to run Sequel for two server hosted business applications, file and print services for the user accounts and is also the Domain Controller for the Active Directory local forest and domain. Six Windows 11 Pro workstations are domain attached to the file server. The workstations all have a local user account and after domain attaching to the file server, a user.Acme user account with Administrator rights to their local computer. Each has its own 192.168.1.x static address and uses their domain user account with mapped drives to access the fileserver. The existing file server name is ACMEWS2012R2, local public static ip 192.168.1.12, DNS Domain Acme.LAN, Netbios name ACME, local accounts are located in \Users\username, and runs SQL Server Express 2012 with default MSSQL database name and mixed security using the SA with password credentials. The new file server will be using Windows Server 2022 (the company apps are not yet certified for 2025) and SQL SVR Express 2022 and I am looking for information about what configuration decisions I can make to hopefully minimize the need to install new user accounts on the workstations, copy all the user folders between users accounts and reinstall applications. My understanding of Domain security is limited, knowing just enough to get workstations attached and properly accessing the file server SQL based applications. My Google results have provided some piecemeal answers, but I would like to better understand the big picture before starting the server upgrade and make some irreversible configuration choices that would cause unnecessary work re-attaching the workstations. I would first ask for recommendations whether and why to keep or change each of the following: The file server machine name The file server 192.168.1.12 IP address The file server Administrator account and password. The Acme.LAN forest and root domain name that was defined after adding the Active Directory Domain Service role that also added File and Print Services and Group Policy Management. The SQL Server Express default MSSQL database name The SQL Server Express SA account name and password I would also ask about the best steps for disconnecting workstations from the old domain then joining the new domain to hopefully retain the existing workstation user account, or if not, minimize the need to copy users folders between the user accounts and / or uninstall then reinstall the workstation applications to properly authenticate to the new user account. I would greatly appreciate some experienced insights for how to best accomplish these upgrade goals. Thanks all.Allow to take RDP from Laptop only and not from IP
Hello Experts, We have scenario where , We want to Allow to take RDP from His Laptop only. Which mean user is allowed to take of RDP of Some Server only from his Laptop and not from any other Computers. We have already checked for Windows firewall but it is working for IP based , and We want for Machine based. as user is roaming between Offices. Please suggest if there is any GPO or Policy or Firewall Rule using which If possible to take RDP using Machine based and not IP based. ThanksWindows Authentication for Entra ID for SQL MI
Hi Team, I recently come across a use case where we have to use Windows Authentication for Entra ID for SQL MI. My question is based on Microsoft documentation https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-setup?view=azuresql There are two options. Options 1 Modern interactive flow Options 2 Incoming trust-based flow Proceeding with Option 2 (Incoming trust-based flow) the authentication flow works some as the following Step Action From To Network Connection 1 Initiate Connection Client (Windows Server 2016) - - 2 Request Kerberos TGT Client Domain Controller (Windows 2012) On-premises network 3 Issue TGT Domain Controller Client On-premises network 4 Request Service Ticket via Kerberos Proxy Client Microsoft Entra ID (via proxy) ExpressRoute (Microsoft peering) 5 Issue Service Ticket Microsoft Entra ID Client ExpressRoute (Microsoft peering) 6 Submit Service Ticket Client Azure SQL Managed Instance ExpressRoute (private peering) 7 Validate Ticket and Exchange for Token Azure SQL Managed Instance Microsoft Entra ID Azure internal network 8 Authenticate User and Grant Access Azure SQL Managed Instance Client ExpressRoute (private peering) If above is correct. Can anyone confirm we have to synchronize service accounts and users to Entra IS that are used by applications? Does the client (running application ot SQL management studio) require access to Entra ID or it will be requested by on-premises AD on behalf of application server Many Thanks !How to move Active Directory Source of Authority to Microsoft Entra ID and why
This gives you seamless access for your teams, stronger authentication with MFA and passwordless options, and centralized visibility into risks across your environment. Simplify hybrid identity management by reducing dual overhead, prioritizing key groups, migrating users without disruption, and automating policies with Graph or PowerShell. Jeremy Chapman, Microsoft 365 Director, shows how to start minimizing your local directory and make Microsoft Entra your source of authority to protect access everywhere. Strengthen your identity security. Sync your on-prem AD with Microsoft Entra ID, adding MFA and Single Sign-on. Start here. Gain full visibility into risky sign-ins. Minimize dual management by moving the source of authority to Microsoft Entra. Check it out. Automate moving groups and users to the cloud. Streamline your identity management using Graph API or PowerShell. Take a look. QUICK LINKS: 00:00 — Minimize Active Directory with Microsoft Entra 00:34 — Build a Strong Identity Foundation 01:28 — Reduce Dual Management Overhead 02:06 — Begin with Groups 03:04 — Automate with Graph & Policy Controls 03:50 — Access packages 06:00 — Move user objects to be cloud-managed 07:03 — Automate using scripts or code 09:17 — Wrap up Link References Get started at https://aka.ms/CloudManagedIdentity Use SOA scenarios at https://aka.ms/usersoadocs Group SOA scenarios at https://aka.ms/groupsoadocs Guidance for IT Architects on benefits of SOA at https://aka.ms/SOAITArchitectsGuidance Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -Your identity system is your first and last line of defense against unauthorized access, data exfiltration, and lateral movement. And now with AI agents acting on behalf of users, identity is more critical than ever. Today we’re going to explain and demonstrate how moving more of your groups and users to centralized management in the cloud can increase your identity security posture without breaking access and authorization to the resources that you have running on premises so that your users don’t even notice anything changed. If we step back in an architectural level, if yours is like most organizations, you’re probably running hybrid identity, where core identity management tasks happen on your local infrastructure, and many of your user, group, app and device accounts are still created or exist on-prem. -And as you’ve started using cloud services, you’ve also set up identity synchronization between your local Active Directory and Microsoft Entra ID so that you can synchronize on-prem objects like usernames, passwords, and groups to the cloud. And if you’ve then gotten the extra step of a Cloud first approach, your new users, apps, and groups are managed in Microsoft Entra by default, and your new managed devices are Entra Joined. Now, you should have implemented multifactor authentication, ideally phish-resistant MFA with device compliance checks along with Single Sign-on for your apps. In both cases, these are really strong foundations. -That said, though, you’re dealing with dual management overhead, on-premises and in the cloud, which can result in less visibility and policy gaps. Moving the Source of Authority to Microsoft Entra to manage identity from the cloud across your digital estate, solves this. Here you’re minimizing your local directory services to only what’s necessary and bringing your existing groups, users and devices as well as your apps and cloud services wherever they live, into Microsoft Entra, which gives you holistic visibility and access control into user sign-ins, risky behaviors, and more across your environment. -In fact, as I’ll show you, this approach even improves controls as users access on-premises resources. The best path to making Microsoft Entra the source of authority is to start with your Active Directory Security Groups where you’ll prioritize the apps that you want to move to cloud-based authentication. Then after working through those, you’ll turn your attention to moving existing user accounts to the cloud. Let me show you how, starting with groups. So here you’re seeing a synced group in Microsoft Entra. The ExpenseAppUsers group has its source in Windows Server Active Directory, as you can see here. In fact, if I move over to the server itself and into Active Directory, you’ll see this group here on top. -Now I’m going to go open that up and you’ll take a look at the group membership tab here, and you’ll see that the group currently has two members, Dan and Sandy. And this is the expense app that we actually want to move. It’s a local on-premises line of business app. So let’s go back to Microsoft Entra and move this group. So we’re going to use Graph API to do this, and for that we’ll need the Object ID. So I’ve already copied the Object ID and I’ve pasted that value into this URI and the Graph Explorer. And of course this can be done using PowerShell or in code, too. And I’ve already run a GET command on this Object ID. And you can see that this new parameter IsCloudManaged equals False below. Now, to change this group to be cloud managed, I just need to patch this object with IsCloudManaged:true. Then I’ll run it. -Now if I select the GET command for that same object. Below, we’re going to see that it’s changed from False to True for IsCloudManaged. And if I go back to Microsoft Entra, we can confirm that it’s cloud managed as the group Source. So now we can add users to the group from Microsoft Entra using Access Packages. So from Access Packages, I’m going to open up the one for our app. Then under Policies, I can see the Initial Policy and edit it. Now moving to the Request tab, I’ll add our newly cloud managed group. There it is, ExpenseAppUsers, and confirm. Now I’ll just click through the tabs and finally update the policy. Of course, self-service access requests and reviews will work as well. And now we can actually try this out by adding users from the Microsoft Entra admin center to grant them access to our on-premises Expense App. -So back in our group for the Expense App, I’ll go ahead and navigate to members and there are the two that we saw before from Active Directory. Now let’s add another member. So I’m going to search here for Mike, there he is, and pick his account, then select to confirm. Now if I take a look at Mike’s account properties and scroll down, we’ll see that he’s an On-premises synced account account. So this account is managed in our local Active Directory, but now the group source of authority is actually in Microsoft Entra and I can grant the account access to on-premises resources as well from the cloud. In fact, let’s take a look at how this appears in our local AD. -So now if I open up our ExpenseAppUsers group and I go to the Members tab, you can see that Mike is there as a new member, synced down from the cloud. Under the covers, this is using a matching Group SID and assigning new members to our local group based on our configurations in Microsoft Entra. So, no changes are even necessary in the local directory or the app. And the point of doing this was to ensure that Mike could be granted access to our on-premises Expense App. So let’s see if that worked. So from Mike’s PC, this is his view of the Expense App and he now has access to that local resource even though I made all the configurations in the cloud. So that was how to get groups managed in the cloud and you’d work through other groups based on the priority of the apps and corresponding groups that you want to move to the cloud. -Now the next step is then to move your user objects to be cloud managed by Microsoft Entra. So here I’m in Microsoft Entra, and I’m looking at our Sandy Pass user account, and we saw her account before in Active Directory. And if I scroll down, you’ll see that her account is indeed managed on premises and synced up to Microsoft Entra. Now the goal here is to ensure that we maintain seamless access to on-premises resources like our app that we saw before, or also file shares, for example, with better security using passwordless authentication. So if I move over to the view from Sandy’s PC, you’ll see that she has a hybrid joined account, and I can access local file shares like this one, for example, for DanAppServer. -Now if I head over to the System Tray, you’ll see that this machine also has Global Secure Access running for on-premises resource access. And next, I’ll open up a command prompt and I’ll run klist to see the issued Kerberos Tickets to show domain authorization is indeed working. So now let’s move this account to be cloud managed like we did with our group before. And the process is pretty similar and equally automatable using scripts or code. Again, we’ll need the Object ID from Microsoft Entra. Remember this text string. Now if I move over to Graph Explorer again in the URI, you’ll see that the Object ID for Sandy’s account is already there and I’ve already run the GET command and IsCloudManaged as you would expect is currently False. So let’s change that property to True. And again, I’ll use the PATCH command like we do with the Group, and I’ll run it. So now if I go over to the dropdown and rerun the GET command, you’ll see that IsCloudManaged is now True. -So if I go back to the Entra portal, we can then head over to the account properties and scroll down and then we’ll see that On-premises sync enabled says No. So, Sandy is now managed in the cloud. In fact, let’s head back over to Sandy’s machine and I’m going to purge the klist just to ensure that there aren’t any residual tickets to grant access to on-premises resources. Now I’m going to run dsregcmd and a switch for refreshprt to refresh the primary refresh token. Then running the status switch, I can get all of the details for the device registration. Then if I scroll down, eventually I can see the OnPremTgt and CloudTgt are both YES, which means the Kerberos ticket, granting ticket is working. -So now if I sign out of this machine then sign back in, the meerkat on screen looks pretty optimistic. So I’ll go ahead and open the Start menu, then I’ll head over to our file share from before and no problems. And I still have write permissions, too. So I’ll go ahead and create a folder, now I’ll name it Employee Data, then drag a file into it just to make sure that my experience wasn’t compromised and everything works. So now if I open up Start and then the Command Prompt and then run klist, there are my two issued tickets for the login as well as the file share access respectively. Again, the account is cloud managed now and we moved from on-premises and we haven’t even affected access or authorization to our resources on the local network. We’re still getting Kerberos Tickets, and our user didn’t even notice the change. -Moving your on-premises groups and user objects to be cloud managed is one of the strongest ways to improve your security posture, add control and better visibility. Now to find out more and get started, check out aka.ms/CloudManagedIdentity and keep checking back to Microsoft Mechanics for the latest tech updates, and thanks so much for watching.
