Fixes for Windows

Fix missing Service Principal Name for ADFS’ gMSA

I’ve been wanting to document this because I had such a bad time with it. I think it stems from Microsoft’s horrible documentation and the army of zealots it hires to copy and paste into their own blogs without fact checking‚Ķallegedly.

Perhaps the most difficult role or task to set up in Windows Server, besides the mere accomplishment of preventing Windows to fuck itself up, it Active Directory Federation Services.

You might be lucky that it manages to complete its setup without warnings or issues but that, if it happens, it’ll be the first time only. It rarely ever happens again. A lot of Microsoft crap is heavily dependent on the directory service and will happily write stuff to it but do a horrible job at collecting its shit when it’s time to go. You’d think after 20 years it should have the ability to self-heal but no, that was split off into another product, System Center, while they still have the nerve to charge you per user and in some cases over time as if improvements were done to warrant it.

Anyway. Rant aside. Fixing the SPN on the gMSA is actually quite easy but it’s buried in a mountain of jargon everywhere in the docu.

You can scroll all the way down if you’re in a hurry, look for text in bold letters and you should be alright.

[First a few] Concepts

Group Managed Service Account, gMSA

If you haven’t read endlessly by now: a gMSA is just like any other user account but with the ability of have its password always fresh automatically. Active Directory takes care of that, it also changes passwords for computer account automatically, if you didn’t know that. This account is invoked to perform tasks on one or more servers, in this case that’d the ADFS farm, whether it’s a single server farm or not.

gMSAs are by default held in the container Managed Service Accounts at the root of your directory. You can use ADSI Edit, AD Administrative Center or AD Users and Computers to find it.

Kerberos Delegation

Behind the scenes and before we get to certificates, communications in Active Directory are secured using Microsoft’s version of Kerberos, an old protocol by MIT. How the whole thing doesn’t matter right now. What you we should focus is on some Kerberos principals, these are:

  • host/federation.domain.tld
  • http/federation.domain.tld

And thanks to Microsoft’s incompetency their NetBIOS forms as well:


This is how your server is named in the directory in its pre-Windows 2000 form.

In my case, my server is federation–you know–to the point. But yours is most likely other thing.

By registering a principal of one domain account into another account, we’re delegating the former into the latter. This is Kerberos Delegation in a nutshell. The service account will represent the service part of the machine and as such it has power to do shit in the server now.

Duplicate SPNs

Let just say I’m by no means an expert on any of this, you shouldn’t even be trusting me. But I’ve tested over and over and observed enough to make my own conclusions and to learn what works.

Kerberos Principals are like IDs on the directory. Two of the same cannot exist. Technically they can, but all sorts of errors ensue.

Sometimes you’ll encounter this annoying error that you have duplicate SPNs, you can query the directory for SPNs using the -Q switch with setspn.

We’re about to enter the command line domain, when you do this in places like Linux, it means power and and honest connection with the system. That’s not true in the Microsoft realm. In Microsoft products you have a lot of code protecting stupid stuff like activation, licensing, and making things found in other platforms deliberatively different enough so they cannot be sued for stealing them. This bullshit adds a lot of layers of unnecessary complexity and this won’t always give you the same results. For instance, I was not able to modify an SPN twice in the same PowerShell window because it suddenly couldn’t find the gSMA.


I have not checked the Windows Server 2019 documentation but up to 2016 this is where they had it wrong. This was copied verbatim to countless of blogs with the same wrong shit.

Microsoft docu states that to manually add the SPN of an ADFS server to a service account you must register its HOST SPN when it fact it’s the HTTP SPN they one that must be registered.

Remember SPNs are like IDs, well, services/capabilitiesOf running in a server sort of have their own identity. HTTP I assume is a web service’s identity.

More importantly, the server itself, needs to have an identity in the directory otherwise there would be no server. The host principal cannot be removed from machine accounts or they become disconnected from Active Directory. If you already did, don’t panic, just add it back to the server (both in FQDN and NetBIOS forms) and restart the server and it should reconnect with the domain as before. You might be able to use Test-ComputerSecureChannel as well for this, I haven’t tested that myself.

The host principal is for servers, the HTTP principal is for service. Therefore you need to add the HTTP principal of the ADFS server(s) to the service account.

First, a little reconnaissance and housekeeping, list all HOST SPNs for every ADFS server you have on your farm. If you’re reading this I assume it’s just the one, otherwise you’d probably would be too knowledgeable anyway, in PowerShell:

setspn -L host/adfsserver

That should match host/adfsserver and host/adfsserver.domain.tld, yup, it seems to work like regular expressions. You’ll get a list by domain account, this should ideally match the machine account with the same name as SPN, but it might be listed under other accounts as well, if that is the case you need to remove it from any other places before adding it back to its machine account. You need to remove it because remember: no duplicates. You won’t be allowed to add it if it exists elsewhere.

You can add the HOST principal using the -R or the -S switches, the -R adds both HOST principals to a computer account at once but if one exists already, you might get an error, so try the -S:

## "adfsserver" at the end of the commands is not a NetBIOS name it's an directory account name so might as well be written "DOMAIN\adfsserver" or "domain.tls\adfsserver" or it will take it just the same.
setspn -R adfsserver
## or with -S (remember that NetBIOS name are usually UPPERCASE)
setspn -S host/adfsserver.domain.tls adfsserver
setspn -S host/ADFSSERVER adfsserver

Now that’s all cleared do the same for the HTTP principal, only this time you’ll remove it from its host and add it to the service account.

There’s actually a dedicated form to do this with setspn but that’s assuming everything’s fine and even so it doesn’t always work:

setspn -U -S http/adfsserver serviceaccount$

If it work, double check with -L. If if not, we still have options. Manually remove HTTP principals from their hosts and add them to the service account:

setspn -D http/adfsserver.domain.tld adfsserver
setspn -D http/ADFSSERVER adfsserver
setspn -S http/adfsserver.domain.tld serviceaccount
setspn -S http/ADFSSERVER serviceaccount
## If it can't find the service account try spelling it with a $ at the end:
setspn -S http/adfsserver.domain.tld serviceaccount$
setspn -S http/ADFSSERVER serviceaccount$
## Still nothing? Try adding in the domain name:
setspn -S http/adfsserver.domain.tld DOMAIN\serviceaccount
setspn -S http/ADFSSERVER DOMAIN\serviceaccount

If you’re still having trouble, there’s always nuclear option: ADSI Edit. Launch the console from the Tools menu in Server Manager or Run adsiedit.msc.

Right-click ADSI Edit in the tree and click Connect to‚Ķ then leave everything as is and just click OK, if you have no other issues with your domain it should connect you correctly to the Default naming context which is your directory except spelled in LDAP. Locate the service account, which should have a name like CN=serviceaccount and a little folder icon. Right-click it and select Properties. Select any attribute from the list and (quickly) type “serv” to fast-forward down the list straight to servicePrincipalName. Double-click it to edit and add http/adfsserver.domain.tld and http/ADFSSERVER, delete anything else if you have more than one server, they add them as well, only HTTP principals, no HOST principals. If PowerShell is still open, run Restart-Computer -Force to reboot the computer without annoying questions.

When the server comes back online in Event Viewer’s or in the ADFS view of Server Manager you should see messages of ADFS starting up.

I hope I have been able to help you and let you continue on what’s very likely the next step of your journey: dealing with ADFS WAP’s own set of issues.

Fixes for Windows

Automatic Logon on Domain Computers


From all the bad advise on this site, this might be the worst yet.

If you still decide to proceed, make sure you’re setting this up on a computer that is not running Remote Desktop (either the built-in service or a third party’s like TeamViewer), not running a remote access services like a VPN server, proxy server, router, NAT, DirectAccess, etc. Make sure remote management tools like as RSAT, Windows Admin Center, WinRM and Remote Registry are either turned off, firewalled-off or both. If possible, use a ultra-low-privileged domain account. If you’re accessing a computer over vSphere’s virtual console, make sure the VM is set to lock when disconnected from the virtual console.

If you have a better method to set this up, please share.

Sometimes you need to run apps that are a pain to set as Windows Services and even if you manage they’re not quite there. You might also have the need to mount network shares as a certain domain user, so local accounts are just not an option.

Setting up automatic login on a domain-join computer is not as easy as [winkey]R control userpasswords2, the only solution I’ve found so far is to set the credentials right on the Windows Registry where they are unencrypted and easily retrievable over a multitude of methods.

You might also be able to set auto-logon up if you have a Microsoft System Center deployment in the network. It seems extremely inefficient even going through the trouble of setting a config policy for this, though.

You need four registry entries to set up automatic login on a domain-join computer, even for local accounts.

The values go in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

AutoAdminLogonREG_SZ (String Value)1
DefaultDomainNameREG_SZ (String Value)<domain>
Can be FQDN or shortname
DefaultUserNameREG_SZ (String Value)<username>
DefaultPasswordREG_SZ (String Value)<password>
Fixes for Windows

Fix Server Manager data retrieval failures (WS-Management Envelope Size)


AdminPowerShell(oneLine): Set-Item -Path WSMan:\localhost\MaxEnvelopeSizeKb -Value 8192

Sometimes in Server Manager you’ll get an error where you can’t get information from other servers.

Manageability: Online – Data retrieval failures occurred

When you click to get more information about the error you get:

servername : Configuration refresh failed with the following error: The WS-Management server cannot process the request. The computed response packet size (519883) exceeds the maximum envelope size that is allowed (512000).

A well-adjusted person would think something is wrong with the remote server, ZPLEX in the example above and it’d be understandable if you went immediately to the remote server looking for something wrong. The something-something exceeds something else, this has clearly an accusatory tone to it: the envelope must be sent smaller so it doesn’t exceed whatever it’s exceeding. It makes sense.

But this is Microsoft software, nothing makes sense. Nothing is straightforward.

Before you go and screw up your remote server, open an Administrative PowerShell in the local server, execute Set-Item -Path WSMan:\localhost\MaxEnvelopeSizeKb -Value 8192

It will behave like BASH, meaning: if it didn’t return any crap, it went through correctly. Refresh Server Manager, information should be pulled correctly now.

Most of the time I use PowerShell because it can also run standard Command Prompt commands. Sometimes an elevated session (Administror-level user, administrative) isn’t even needed, but if it isn’t needed it could not hurt so I go with that.

When Microsoft decided to distract people with PowerShell instead of doing a good GUI, they assigned new names to the old commands and gave them shortcuts using their old names plus shortcuts using what a matching command would be in BASH.

For instance, move is now Move-Item, or mv in BASH. dir is now Get-ChildItem, or ls in BASH.

To fix this Envelope nonsense they didn’t come up with a different version though, if you want to use a Command Prompt window (cmd.exe) you need to run the following:

To get the current envelope size: winrm get winrm/config you’ll get a lot of data, make your windows taller or scroll up, the value will be on the very first of the Config section.

To set a working value: winrm set winrm/config @{MaxEnvelopeSizekb="8192"}

Fixes for Windows

Change the default Organizational Unit where machine accounts drop

This is an easy one.

If you want to customize your directory’s default location for newly-joined machine accounts (that do not specify OU where they wish to join), it’s a single 2-part command.

As is the norm with these tasks, launch an Administrative PowerShell and run redircmp OU=Devices,OU=MyDomain,DC=example,DC=tld. If your there are spaces on the address of your LDAP tree, wrap the LDAP string in “”, e.g; redircmp "OU=Awaiting Placement,OU=My Domain,DC=example,DC=tld". Windows is very forgiving with whitespaces but it’s best to be sure. Microsoft is not know for consistency.

Remember, Domain Controllers go into their own thing. Ignore them as much as you can and keep forcing replication (repadmin /syncall). If you change too many things.

Fixes for Windows

Repair computer’s relationship with domain

Sometimes you go on a cleanse and decide it’s fine to move around computers in your directory, or perhaps forgot to disconnect the network from VM clone causing conflict in the directory.

Power losses, bad time, machine- or machine’s password resets are a few of other things that can cause a computer’s relationship with the domain to break.

Forcing the machine to leave the broken relationship and rejoin the domain will fix this but may also cause loss of data from the lingering files of a roaming user profile, for instance.

This is also not an option if the machine happens to be an Enterprise Certificate Authority. CAs cannot be unbound from AD while they hold the role.

To test that a machine has a valid relationship with the domain, launch an Administrative PowerShell and run Test-ComputerSecureChannel right away you’ll get a true or false.

If it’s false, fix it with Test-ComputerSecureChannel -Repair -Credential domainadmin@example.tld.

BTW, it’s fine if you try to repair where it’s not broken.

If you run this on a domain controller, you’ll get a huge error.

You’ll need to use an account with privileges to domain-join; you’ll be fine using a Domain Admin’s or an Enterprise Admin’s account.

A new window will pop up to enter the account’s password, the user account will be prepopulated. Despite the nonsensical redundancy, -Credential switch is needed in the PowerShell syntax.

Fixes for Windows

Install Telnet (client) on Windows

Back when my mind was becoming slightly untethered trying to route email directly from my server, I came across one email relay that was willing to forward me my email from their servers for free but I had to guarantee things were in working order; which is completely fair of course.

It was then when I learned that a Telnet client besides of its normal outdated SSH-like functions, it also works to check on open SMTP ports. Telnet, though not immediately obvious, still comes with Windows.

Windows Server

In the Server family, it’s available as part of Windows’ Features. To install use Server Manager and add the feature to the server you wish.

The faster way is with an Administrative PowerShell window; execute Install-WindowsFeature -Name Telnet-Client

Non-Server Windows

Yep… Each passing moment Microsoft and Apple lock things more and make it more difficult for you to find settings that might reduce telemetry or allow you install things where they don’t get a cut when the purchase wasn’t made through their stores for your security.

Fixes for Windows

Fixes for Windows

When I say Windows, I really mean anything done my Microsoft. If you’re deploying/using a product made my Microsoft and the magical migration doesn’t go as planned. Even purchasing is a nightmare and they sell you direct. Don’t be too hard on yourself. Microsoft’s products never work as advertised, they’re sort of geniuses at that actually–if only they’d applied their smart at doing something half-assedlessly. You probably wouldn’t be here, I guess.

A recurring thought of mine for years has been Microsoft never disappoints disappointing.

Fix Macs’ scrolling in Windows

Useful for those times you wipe macOS on a whim and remember about the Boot Camp drivers too late when you tried to scroll down Windows’ EULA and it went the other way.

Open an Administrative PowerShell and run:

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Enum\HID\*\*\Device` Parameters FlipFlopWheel -EA 0 | ForEach-Object { Set-ItemProperty $_.PSPath FlipFlopWheel 1 }

Here I have witnessed some weird behavior if you don’t restart the system immediately. Either do what you need to do and then execute the command or do the command, restart and continue doing what you were after the restart. From PowerShell you can execute Restart-Computer -Force to more or less guarantee the system won’t hiccup restarting. Though this is Windows: no guarantees. Restart-Computer does a normal restart.