Error Doing a Full Data Sync

Today I am setting up a proof of concept for the retail solution in AX 2012 R3. As a base I am using the Microsoft AX 2012 R3 demo VM deployed to Azure using LCS

When Trying to do a  full data sync I got the following error:
”The target principal name is incorrect. Cannot generate SSPI context”

SSPI context has to do with Service Principal Name in Active Directory. The Service Account for SQL (contoso\sqlsvc) needs to have SPN set like this:

setspn –A MSSQLSvc/AX2012R2A:1433 contoso\sqlsvc
setspn –A MSSQLSvc/ contoso\sqlsvc

Where AX2012R2A and are hostname and FQDN for the AX demo VM.

In my case I had duplicate FQDN and no hostname. I cleaned out the duplicates and added the hostname.


Nice to know: What is going on during logon

When you are logging onto a Windows machine you will sometimes notice that it is taking a long time… usually you just blame GPOs and move on… If you want to get a hint on what´s taking so long you can set a GPO setting which turns on detailed information during logon


There are two different settings depending on which OS you are running (pre 2008R2/2012 or later)

You will find the setting in gpedit under Computer Configuration – Administrative Templates – System

The setting is called:

Pre 2012: Verbose vs normal status messages

Post 2012: Display highly detailed messages


Active Directory Based Activation

In Windows 2012 there is a new method of activating Windows Servers/Clients and Office. The method is called Active Directory Based Activation and is an alternative to KMS and MAK activation. It works by adding a Activation Object to Active Directory which activates computers joined to the domain.

  1. First we need to install the Volume Activation Tools from Server Manager (Volume Activation Tools is just the tool to create the activation objects in AD. Active Directory Activation does not require any server components)
  2. Second we need to add the KMS key. And activate it


  3. To install an office key you will need to download and install Microsoft Office 2013 Volume License Pack
  4. When the install is done the Volume Activation tool will pop up and allow you to add the key

Note 1: The Windows Server 2012 R2 key will also activate clients

Note 2: Active Directory based activation works for Windows 8/8.1, Windows Server 2012 / 2012 R2 and Office 2013. For older versions you will need a KMS server.

Note 3: Since the activation object is stored in AD it is replicated to all DCs which means that all DCs can act as an activation server


Manage Local Admin Passwords – Additional Comments

Todays work consists of implementing a system for managing local admin passwords for Servers and Workstations in an Active Directory Environment. I have used the method in the following (excellent) article series from the PlatformPFE team at Microsoft.

Part 1 – Overview
Part 2 – Random Password Generation
Part 3 – Secure Active Directory Attribute Update
Part 4 – Update Local Account’s Password
Part 5 – Logging The Update Process
Part 6 – Extending The Active Directory Schema
Part 7 – Managing Local Administrators Passwords

In short this series uses a new attribute in AD (set to confidential) to store the local admin password. The password is changed and written to the attribute using a powershell script which is run on every startup of a computer.

There are some aspects of the solution that where not completely obvious to me so I thought I would write the down so I won’t forget them:

The Confidential attribute is a flag that is set on the attribute which requires not only Read Permissions but also CONTROL_ACCESS to the attribute to be able to read it.

There are some limitations:

  • The confidential flag cannot be applied on most of the default attributes. It is however applied to some default attributes such as Bitlocker Recovery Keys
  • The CONTROL_ACCESS permission is default set for members of administrators and account operators in active directory which means that these users will always have access to to confidential attributes.
  • The CONTROL_ACCESS permission can only be set using LDP.exe (which I will explain later how to do). You will need to do this if you want to allow users not member of  administrators and account operators to access the local admin password

To set the CONTROL_ACCESS permission for the AD-MemberServers OU-Read-Attribute-LocalAdminPWD group (described in the series), do the following:

  1. Start LDP.exe elevated as a Domain Admin User
  2. Connect to your domain controller


  3. Bind LDP to the domain using your user account


  4. Turn on the tree view in LDP

    image image

  5. Browse to the OU where you set up permissions and open Security Descriptor


  6. Double-click the ACL you set to open it and check the Control Access box. Click OK when you are done

    Note: If you set up the  password solution for Workstations to you will need to repeat the procedure for the workstation OU

  7. Done


To verify if all computers have a local admin password set you can run:

$Filter = {(-not(LocalAdminPWD -like “*”))}
Get-ADComputer -Filter $Filter  -Properties LocalAdminPWD | ft Name,LocalAdminPWD


AD Demotion

I am currently helping a customer with upgrading all of their old DCs. When I tried to demote one of the DCs I got the following error message:

Title bar text: Active Directory Domain Services Installation Wizard
Message Text:
The operation failed because:
Active Directory Domain Services could not transfer the remaining data in directory partition
DC=DomainDNSZones,DC=<DNS domain name>
Active Directory Domain Controller
“The directory service is missing mandatory configuration
information, and is unable to determine the ownership of floating single-master operation roles.”

The problem is that each of the application Partitions for DNS has a FSMO and this name is present in more than one place. If these location does not match you will get the above error. To verify that this is actually the problem you can check the following parameters in ADSI Edit:

In ADSI edit connect to Default naming context and browse to CN=Infrastructure,DC=domain,DC=local and verify fSMORoleOwner

Then connect to CN=Infrastructure,DC=DomainDNSZones,DC=domain,DC=local and check that the fSMORoleOwner is the same as above. Perform the same operation for CN=Infrastructure,DC=ForestDNSZones,DC=domain,DC=local

If these do not match up the is a VB Script from MS you can use to fix it:

const ADS_NAME_TYPE_1779 = 1

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
    ‘ Assume the command line argument is the NDNC (in DN form) to use.
    NdncDN = inArgs(0)
    Wscript.StdOut.Write “usage: cscript fixfsmo.vbs NdncDN”
End if

if (NdncDN <> “”) then

    ‘ Convert the DN form of the NDNC into DNS dotted form.
    Set objTranslator = CreateObject(“NameTranslate”)
    objTranslator.Init ADS_NAME_INITTYPE_GC, “”
    objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
    strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
    strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
    Wscript.Echo “DNS name: ” & strDomainDNS

    ‘ Find a domain controller that hosts this NDNC and that is online.
    set objRootDSE = GetObject(“LDAP://” & strDomainDNS & “/RootDSE”)
    strDnsHostName = objRootDSE.Get(“dnsHostName”)
    strDsServiceName = objRootDSE.Get(“dsServiceName”)
    Wscript.Echo “Using DC ” & strDnsHostName

    ‘ Get the current infrastructure fsmo.
    strInfraDN = “CN=Infrastructure,” & NdncDN
    set objInfra = GetObject(“LDAP://” & strInfraDN)
    Wscript.Echo “infra fsmo is ” & objInfra.fsmoroleowner

    ‘ If the current fsmo holder is deleted, set the fsmo holder to this domain controller.

    if (InStr(objInfra.fsmoroleowner, “\0ADEL:”) > 0) then

        ‘ Set the fsmo holder to this domain controller.
        objInfra.Put “fSMORoleOwner”,  strDsServiceName

        ‘ Read the fsmo holder back.
        set objInfra = GetObject(“LDAP://” & strInfraDN)
        Wscript.Echo “infra fsmo changed to:” & objInfra.fsmoroleowner

    End if

End if

Paste it into a file called fixfsmo.vbs and run it

cscript fixfsmo.vbs DC=ForestDnsZones,DC=domain,DC=local
cscript fixfsmo.vbs DC=DomainDnsZones,DC=domain,DC=local

Konstiga beteenden för Get-ADUser

Dagens problem har med Get-ADUsers att göra… De flesta miljöer jag arbetar i är uppgraderade till 2012 eller senare men just denna kund har inte uppgraderat…

Dagens uppdrag var att skapa en CSV export av AD användare så jag började med:

Get-ADUser -Filter * -Properties * –Searchbase “OU=OUn,DC=Domain,DC=se”

Detta spottade ur sig en hel hög med fel… Suck

Jag testade det i min labbmiljö och det funkade… efter lite letande hittade jag att det verkar vara ett problem med Schema versionen… antingen uppdaterar man eller får man testa en workaround:

Get-ADUser -Filter * -Property * –Searchbase “OU=OUn,DC=Domain,DC=se”

verkar fungera (observera Property istf Properties)

Get-ADUser –Filter * –SearchBase “OU=OUn,DC=Domain,DC=se” | get-ADObject -Properties *



Back to basics – FSMO Roles

Today in class I hade a student who had a Windows Server 2012 Essentials migration that did nor succeed. The reason was that the FSMO move did not complete.

To list all the FSMO roles using NTDSutil:

   1: ntdsutil: roles

   2: fsmo maintenance: connections

   3: server connections: connect to server [TheNameOfYourDC]

   4: server connections: q

   5: fsmo maintenance: Select operation target

   6: select operation target: List roles for connected server

To seize all the FSMO roles using NTDSutil:

   1: fsmo maintenance: Seize domain naming master

   2: fsmo maintenance: Seize infrastructure master

   3: fsmo maintenance: Seize PDC

   4: fsmo maintenance: Seize RID master

   5: fsmo maintenance: Seize schema master

If you, like in this case, have a broken DC, remember to delete the object from AD Users and Computers and Sites and Services


Network Time Protocol

Today I would like talk a little about setting up NTP sync in Active Directory… as you might know time is quite important in Active Directory because Kerberos is dependant on it. If the time difference is higher than 5 minutes (default setting) you will not be able to log in

I visited a customer today who had a problem which meant that they could not set up NTP sync…

We used these commands to verify operations on the PDC emulator:

   1: w32tm /query /status

   2: w32tm /query /peers

   3: w32tm /query /configuration

Apparently it used local CMOS clock as a time source, so we set up external NTP peers

   1: w32tm /config /syncfromflags:manual /manualpeerlist:",0×1,0×1" /update /reliable:yes

… which did not help, we then did a reset of the time server settings on the PDC emulator:

   1: net stop w32time

   2: w32tm /unregister

   3: w32tm /register

   4: net start w32time

We the registered the new NTP peers:

   1: w32tm /config /syncfromflags:manual /manualpeerlist:",0×1,0×1" /update /reliable:yes

The server still reported that it synced from the local CMOS clock. After some looking around we found that there was a policy setting in the Default Domain Policy which disabled the NTP Client. You will find this setting in Computer Configuration – Administrative Templates – System – Windows Time Service – Time Providers and it is called Enable Windows NTP Client. So I changed it and refreshed the group policy and that did the trick

To set up the rest of the DCs to use the PDC emulator as a time source you use this command

   1: w32tm /config /syncfromflags:domhier /reliable:no /update

To enable and disable debugging of NTP use:

   1: w32tm /debug /enable /file:C:\Temp\w32tmdebug.log /size:10485760 /entries:0-300

   2: w32tm /debug /disable

To resync the computer with its time source use:

   1: w32tm /resync

To compare your NTP servers time with an external time source

   1: w32tm /stripchart / /samples:5 /dataonly

Finally you also need to verify that your server is able to communicate to the timeserver using UDP port 123


Creating new Active Directory objects with Windows Server Essentials where the belong

To day we are going to take a look at a little strange behavior in Windows Server 2012 Essentials. But first we need to look back to remember our history…

Back on SBS 2003/2008/2011 Standard the install created an OU structure that looked like this:


all new users was created in  ou=SBSUsers,ou=Users,MyBusiness,dc=innoworks,dc=local

In Windows Server 2012 Essentials things are done a little different… all new users and computers are created in… wait for it…

cn=Users;dc=domain;dc=com and cn=Computers;dc=domain;dc=com

Of course this is what SBS 2011 Essentials also did. So for all of you, who like me like to have things organized something like this


You can use the following commands for setting up where objects are created by the dashboard

redirusr ou=Users,ou=InnoWorks,dc=innoworks,dc=local
redircmp ou=Computers,ou=InnoWorks,dc=innoworks,dc=local

This means that if you are migrating from SBS Standard you can use these commands if you want to keep the OU structure set up by SBS