Category: Active Directory

Duplicate SRV records are cousing domain join workflows to fail

Have you ever had problems with duplicate SRV records in your environment? This is a quite common phenomenon when you google it without any real solution to it (not at least what I could find). Some environments would not be affected by this, but I got into a specific situation recently where some workflows in Nutanix would fail because of duplicate SRV records.


  • Duplicate SRV records, one in lower-case – one in upper-case, are causing some workflows in Nutanix to fail.
  • When deleting the oldest record the duplicate is just recreated after some period of time (like 30 minutes or so).

So whats cousing this? In this specific case we managed (together with Microsoft support) to isolate the issue and found out that there were two main things that were related to this behaviour listed below.


  • Some Domain Controllers names were in lower-case, others in upper-case.
  • When you have a mixture of DNS servers running Windows Server 2012 and 2016 the way that machine names are registered differs between those Windows versions.

So how do we solve this? The preferred solution from Microsoft was to rename all domain controllers to lowercase, but since all Domain Controllers except one, in this case, was in uppercase we tried to rename that specific DC to uppcase instead. The following steps were performed on the server:

    1. Demote DC
    2. Rename to uppercase
    3. Promote DC
    4. Delete all duplicated SRV records in DNS
    5. (If  the issue is still happening):
      1.  Stop netlogon service
      2. Delete C:\Windows\System32\config\netlogon.dnb
      3. start netlogon service

After doing this the duplicate SRV records stopped being recreated in the environment.


  • The preferred way to solve the issue is to rename all domain controllers to lowercase (or uppercase which works too).

If you have any questions, feel free to email me at or comment down below. I will try to answer you as soon as possible.

Azure AD Connect and .NET Framework 4.7.2


Last week a discussion erupted on Microsoft forums regarding Azure AD Connect due to it’s Monitoring Agent using all free resources of CPU on the servers. These issues were caused by a .NET Framework update and a lot of administrators spent time uninstalling and blocking these patches to resolve the CPU usage issues on their servers. On Saturday Microsoft released an update (KB4340558) which contains a collection of several patches where one of the earlier mentioned .NET Framework updates were included. For more information, see this link.

Microsoft has recently published an article regarding this issue. In addition, Microsoft also published a new version of the health agent where they state that the issue is resolved, it can be downloaded from here. The new health agent version is set to be included in the next version of Azure AD Connect, which will be published for Automatic Upgrade (Auto Upgrade). The following patches have been identified with issues causing Azure AD Connect’s monitoring agent using huge amounts of CPU:

Auto Upgrade

In version of Azure AD Connect, Microsoft introduced Auto Upgrade. Although, not all updates are published for Automatic Upgrade. Whether a version is eligible for automatic download and installation will be announced on Microsofts version-history website for Azure AD Connect.

You can verify whether your Azure AD Connect installation have Auto Upgrade enabled by either using Powershell or viewing your configuration in It’s GUI.

Graphical User Interface of Azure AD Connect
PowerShell-command for determining whether Auto Upgrade is enabled or not.

This command will return either Enabled, Disabled or Suspended, where as the Suspended state only can be set by the system itself. Newer installations of Azure AD Connect enables Auto Upgrade by default, in case your installation applies to Microsoft’s recommendations. For more information, see this link.

Enabling Auto Upgrade

In case you have an installation of Azure AD Connect older than (February 2016), Auto Upgrade will be disabled, if you’ve not enabled it manually. Enabling this function can be done with below PowerShell-command if so wanted.

If you have any questions, feel free to email me at

Specific computer model not joining the domain.

I recently had an issue with a specific computer model not joining the domain. The Task Sequence had not been updated for a while, and we had not done any significant changes to the environment. With other computers working flawlessly, we had issues with a HP EliteDesk 800 G3 DM 35W not joining the domain for some unclear reason. This was the start of an interesting discovery.

The issue began when this EliteDesk 800 G3 wouldn’t join the domain. Usually when a Task Sequence finishes, the computer reboots and you see a login screen, stating the domain and asking for credentials, as shown in this picture.

Usual image after a successful Task Sequence

This time the EliteDesk didn’t show any domain, just asking for local Administrator credentials. My first guess was network drivers, so I started by updating the boot image with fresh network drivers for EliteDesk 800 G3. Even with up-to-date drivers the computer wouldn’t join the domain. I started going through the SMSTSLog, BDD.log, checked if something had failed during the Task Sequence. No errors were found. But still, the computer would not join the domain.

I started digging deeper and went through the “panther\UnattendGC\setupact.log” and the “debug\NetSetup.log”. It was here where I started to find some interesting issues.

We have an environment built around an OU structure based on location and computer type (desktop, laptop or virtual machine). The ComputerTypeOU property is saved in to a variable used in the Task Sequence. What OU the computer is added to is decided in the CustomSettings.ini-file. 

In both the setupact.log and NetSetup.log I found out that no value was saved in the “%ComputerTypeOU%”-variable.

NetSetup.Log of EliteDesk 800 G3 DM 35W

My initial thought was that the log prints the string without any value connected to the variable, but after going through the same logs on a newly installed computer, that had no issues joining the domain, I quickly found out that I was wrong. The variable should definitely contain the value generated by the CustomSettings.ini file.

NetSetup.Log of EliteBook Folio 9480m

As shown in the first image, the EliteDesk 800 G3 did for some reason not receive any value to this variable. I started going through logs once more, trying to find out why this computer was unable to fetch the required value.

Since we unfortunately do not have an OU named “%ComputerTypeOU%” in the domain, and the Join Domain-account was unable to create one, the computer did not join the domain because of the account used in our Task Sequence having insufficient rights.

But why this variable was missing its value was the main question. I started going through logs again, and this time I had something to look for instead of searching for the unknown. The BDD.log gave me a good overview of all the client properties. I compared a domain joined client with the EliteDesk 800 G3. Here I stumbled upon an interesting fact. The EliteDesk did not report as a laptop, a desktop nor a server, as shown below.

BDD.Log of a EliteDesk 800 G3 DM 35W

BDD.Log of a EliteBook Folio 9480m


Since the EliteDesk 800 G3 did not report any of the values needed for our structure, the solution was to add Model to the Priority list and associate EliteDesk 800 G3 with the “ComputerTypeOU”-property set to workstations.

After adding the Model property to the CustomSettings.ini file, the EliteDesk 800 G3 joined the domain flawlessly after running a Task Sequence.

This might not be the best solution to this matter, but it sure is a practicable fix. If anyone has a preferable solution, feel free to email me at

How to join a Windows 10 computer to your Azure Active Directory


Some of the benefits of having your Windows 10 devices in your Azure AD is that your users can join the computer to your Azure AD without any extra administrator privileges, assuming you have configured this in your Azure AD. They can also login to the computer without the need of being connected to a specific company network the first time, as long as they have internet connection. You can also manage your Windows 10 devices wherever it may be in the world.

Windows 10 Subscription Activation for Hybrid Azure AD Joined devices

In a migration phase to Windows 10 we wanted to be able to benefit from the fairly new Windows 10 Subscription Activation method for the existing environment. One of the requirements for us was that we could do this with Hybrid Azure AD Joined devices. With this post I will try to guide you through the settings and steps for the setup to work properly.

In this scenario the environment looked like this from the beginning:


Domain functional level: Windows Server 2012 R2
Windows 7 machines ready to be upgraded to Windows 10
All Windows clients domain-joined to an on-premise domain
An active Office 365 tenant existed
Azure AD Connect was configured with password synchronization only
An active Azure AD Premium P1 subscription existed


Now when we got the background information about the environment, lets start listing the things we needed to do before we successfully could make the Windows 10 Subscription Activation work for the new Windows 10 devices.

  1. Configure a service connection point
  2. Enable device writeback in Azure AD Connect
  3. Sync computers accounts via Azure AD Connect
  4. Create a GPO so domain joined computers automatically and silently register as devices with Azure Active directory
  5. Upgrade existing computer or install a new one with Windows 10 Pro 1709 and on-premise domain-join the device
  6. Verify that the Windows 10 computer register as a Hybrid Azure AD Joined device in Azure Active Directory admin center
  7. Assign a Windows 10 E3/E5 license to a user in Office 365 Admin Center
  8. Log onto the computer with the user you assigned the license to
  9. Confirm that the Windows 10 Pro 1709 computer steps up to Enterprise


Now I will describe most of the steps in more detail so it’s easier for you to understand what needs to be done.


To configure a service connection point, follow the steps below:

In newer versions of Azure AD Connect and when running Express settings, this SCP is created automatically here:

You can also retrieve the setting with PowerShell:

In this case, it had not been created, probably because older version of Azure AD Connect was installed that did not perform this. Run the commands below as admin from the Microsoft Azure Active Directory Module for Windows PowerShell on the Azure AD Connect server which also needs to have RSAT-ADDS installed to create the SCP. Make sure you have 1.1.166 of the module installed.

Verify that the SCP has been created with the retrieve PowerShell command above.

To enable device writeback in Azure AD Connect and sync computer accounts, follow the steps below:

This is done from the Azure AD Connect server.

To create the GPO for domain joined computers to automatically and silently register as devices with Azure Active directory, follow the steps below:

To verify that the Windows 10 computer register as a Hybrid Azure AD Joined device in Azure Active Directory admin center, follow the steps below:

You should also see msDS-Device records in the RegisteredDevices OU in Active Directory.

To assign a Windows 10 E3 or E5 license to a user in Office 365 Admin Center, follow the steps below:

In your Office 365 admin portal, find the user who should log onto the Windows 10 Pro computer and activate the Windows 10 Enterprise license that you bought beforehand. This license can be purchased as a separate license or via Microsoft 365 E3 or E5 license bundle.

To verify that the computer has been activated through Windows 10 Subscription Activation, follow the steps below:

After logging onto the Windows 10 Pro computer, verify that the Enterprise version has been activated.


Please note that you need to have a Windows 10 Pro license activated to get this to work. If you have a Windows 7 Pro licensed computer today and you have bought the Windows 10 E3/E5 or Microsoft 365 E3/E5 license you can upgrade your existing Windows 7 Pro computer to Windows 10 Pro by using your existing Windows 7 Pro key. This will give you a valid Windows 10 Pro license that can be used in this scenario.

A good to know command in this hybrid scenario is dsregcmd.exe /status. It will give you the status of your local computer, like if the device is Azure joined or if the user is in Azure.

If you have any questions, feel free to email me at

You can find Microsofts documentation here.

Backup av Active Directory

Många använder sig utav 3:e partsprodukter som Veeam B&R, Unitreds/PHD Virtual, Backup Exec m.m för att ta backup av sin infrastruktur där flera av dessa har stöd för Application-Aware  / VSS vilket möjliggör backup av domänkontrollanter och Active Directory.

Detta är klockrent när man ska återställa en hel miljö och för att Active Directory ska starta upp korrekt, men vill man bara återställa en GPO eller jämföra inställningar i schemat mellan två förändringar blir det lite omständigt.

Något vi därför rekommenderar våra kunder att utöver VM backup av sina domänkontrollanter, även ha backup och revisionsbackup av följande från minst en DC (per domän).

  • Group Policy Objects
  • DNS
  • DHCP
  • Netlogon
  • Schema
  • Windows System State

Utöver ovan, rekommenderar vi att man har aktiverat Active Directory Recyle Bin i sin miljö för att återställa borttagna AD-objekt.

Detta är för att man inte ska behöva återställa ett helt VM från backup, starta upp utan nätverk, leta upp vad man söker efter och återställa det utan man enbart öppnar katalogen från ett tidigare datum, exempelvis öppnar man sin DNS-backupen i Notepad och direkt kan man jämföra dessa emot produktionsmiljön. Detta går betydligt snabbare och blir avsevärt mycket enklare i felsökning men även återställningssyfte.

Group Policy Objects

Ett enkelt sett att ta backup av Group Policy Objects är att använda sig utav PowerShell för att dels ta backup av alla men även en rapport för att få en enkel översikt över vad dem innehåller i HTML-format.

Resultatet blir som följande:

GPO Backup


För backup av DNS använder vi oss återigen av PowerShell som gör en export av alla DNS zoner som finns upplagda på en DC.

Varje DNS zone hamnar då i en egen text-fil som kan enkelt öppnas och utläsas:

DNS Backup


DHCP är något som vi ser är vänligt att man lägger på en domänkontrollant, ibland kan det vara bra och ibland mindre bra. Tidigare har det varit problematiskt om man behöver starta om en domänkontrollant eller om man ska ersätta den men i Windows Server 2012 R2 finns möjligheten till DHCP Failover vilket gör att man kan ha 2st servrar som replikerar DHCP-scopet mellan varandra och båda kan dela ut en IP-adress utan att krocka med varandra. Detta är en klockren funktion som Microsoft levererat för redudans men vad händer om man vill kunna jämföra inställningar mellan olika dagar eller tappat en inställning? Då är det smidigt att ha tagit både en dump och en export av DHCP-scopet som kan läsas ut i textformat.

Skillnanden på en export och en dump är att en export används vid import medan dump kan du enkelt läsa inställningarna:

DHCP Export Dump


Netlogon används ofta för att spara inloggningscript, därför tycker vi det är smidigt att göra en kopia av katalogen för att kunna gå tillbaka om något skript uppdaterats som slutar fungera.


En av de mest känsliga bitarna i Active Directory är schemat. Schemat behöver vara fungerande för att diverse olika tjänster och produkter ska fungera, t.ex Exchange, Skype m.m.

Det vi har med i vår backup är helt enkelt en export av Configuration, Schema och Default Naming Context via ldifde.

Filerna sparas i .ldf format men kan öppnas med exempelvis Notepad för att läsa ut informationenSchema Backup

Windows System State

Sist men inte minst, Windows System State backup av en domänkontrollant. Detta är något som vi anser är viktigt att ha med som komplement till VM backup av en domänkontrollant.

Backup via ett 3:e partsverktyg innehåller oftast samma sak som en System State Backup och är det Application-Aware är tanken att det även ska använda samma VSS Writers som System State gör. Fördelen med att använda sig utav Windows System State via Windows Server Backup är att det är ett verktyg utvecklat av Microsoft, för Microsoft produkter och man kan få support av Microsoft.

OBS: En System State backup innehåller inte all information från en maskin utan är begräsnad, läs mer här om vad som inkluderas. Vill man inkludera mer går det självklart bra men detta är som sagt ett komplement till 3:e partsbackupen och inte en ersättare. 

Att tänka på

  1. En domänkontrollant ska vara en domänkontrollant och inget annat. Installera alltså INTE andra roller på den så som CA, Print, File etcetera.
  2. Återställ inte en domänkontrollant om miljö fungerar korrekt och inte har några kända problem. Skrota DCn och sätt upp en ny istället – det blir enklare ochman får en nyinstallerad DC.
  3. Säkerställ att man har supporterat backup (från både Microsoft och 3:e partsleverantören)  på plats
  4. Genomför kontinuerliga teståterläsningar och ha tydliga rutiner vid återläsning
  5. Begränsa åtkomst till backupshare. I och med att man läser ut så mycket och det ligger i “klartext”, säkerställ att man har begränsad åtkoms till sökvägarna och sharen där backupen ligger.