2026-01-11

inter-domain object move

Until yesterday, I was convinced, that inter-domain (in the same forest) is strictly impossible. I did huge migrations, hudreds thousands of objects and I thought that inter-domain migration is impossible. Yesterday I found document or notice regarding movetree.exe but:
  • new object in destination domain retains the same object guid, but of course - sid is different - most of migrations requires the same sid and the same guid or to properly process new object and treat as the new as the old one (to mimic)
  • new object has the old sid in sidHistory - ok
  • the old object is deleted and can't be simply refurbished

In our huge migrations every time we created a new bunch of objects - in the same forest or in different forest, every time we used sidHistory, the old objects remains intact - just to have flexibility in operations. Every user profile with exchange mailbox/outlook profile was also migrated before the final switch, so... if userA in domain1 (domain1\userA) was prepared for switch, so his user profile with outloook profile was prepared for this operation and in M-Day (migration-day) he could just login on userA account in domain2 (domain2\userA) so he could still work with the same environment.

MoveTree scenario is possible only in a small environments, in small migrations.

what's wrong - domain controller or different source?

what's wrong possible source solution
time unsynchronized pdc role
domain controller
verify if pdc is synchronized with external time source
verify if dc are synchronized with pdc
users can't login time synchronization (Kerbers)
802.1x issue
check domain controllers if they are synchronized
are certificates ok for 802.1x? crl are available?
users change password issues pdc role availability maybe something wrong is with pdc role dc?
can't join a new computer to domain limit per user account of new computers
availability of RID master
increase limit
check if RID master is available - dc don't have rid pool to assing
can't create new objects - uses, groups, computers availability of RID master check if RID master is available
universal group membership failure infrastructure master
global catalog availability
infrastructure master is not updating links between domains because is on global catalog
check if global catalog is available

to-do november 2025

What subjects I must focus:
- TGT on a trust - reset -

2025-08-09

SPN with IPv4 or IPv6 addresses

Starting with Windows 10 version 1507 and Windows Server 2016, you can configure Kerberos clients to support IPv4 and IPv6 host names in SPNs. Yes, it is again possible - as I can remember - it was disabled on Windows 2008 r2 or maybe Windows 2008, up to these versions it was possible.





Entry in registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

DWORD:TryIPSPN, value = 1



SPN value must be registered in Active Directory or course.

2025-08-06

Windows 11 - customize taskbar

It's impossible to have taskbar on the top, on the right or on the left - the only position and the best position according to Microsft is the bottom. Next stupid choice like "only one button" in IOS devices. Users don't know what is the best for Them, but of course - one guy - Satya, Bill or Steve knows. What an idiotic choice.
Is there a sollution? Of course, please praise the lords and ask them of one stupid option.
Registry customization is not working. What audacity to think that change could be so simple by using only registry. It's must be hardened in binaries to prevent such brave steps.

2025-07-21

DNS CAA proper internal configuration

What is a valid configuration of internal CAA records (internal - not visible in Internet) on Windows DNS servers:
  • You should point to valid source of certificates - "issue" prefix for DNS record, for example if Your internal PKI is from pki.internal.contoso.com you should place record issueinternal.contoso.com or issuecontoso.com; this will cover also wildcard certificates;
  • If You don't want to allow wildcards You should place another DNS record with empty source record like "issuewild;" - allowed entries is empty; 
  • binary representation  of DNS record contains first byte equal zero (the higest bit has critical meaning, rest is not used now), next byte value 5, rest of record is a string data, e.g. "<00><05>issuewild;"
  • binary representation must be located in DNS record of Type257

2025-06-17

ADFS certificate renew with Azure, Entra ID and M365

We have ADFS 4.0 farm without WAP (security reasons) so we don't have strict accessibility from Internet - only communication between on-premise and Azure from selected networks and addresses. Why it is important? Probably we've been had some issue with renewal process.
According to Renew federation certificates for Microsoft 365 and Microsoft Entra ID we should enable rollover on certificates and after controlled switch between primary and secondary certificates our federation between Azure and ADFS should be updated, but:
  • the next signing certificate on Azure was from two periods ago (one period is 2 years, so it was 4 years old, now we have certs from 2025 to 2027, previous period it was 2023 to 2025, but two periods ago it was 2021 to 2023)
  • so the next signing certificate wasn't updated till 4 years
  • on daily basis we have AutoCertificateRollover disabled
  • when it should be enabled? just before enforced generation of the new certificates? it wasn't
  • so we changed it manually - after replacement of certificates (flip between secondary and primary) they've been exported to base64, imported in powershell (copy paste from .cer file to variable)
  • connection to Entra - Connect-Entra -Scopes 'Domain.ReadWrite.All' (different possible values are like User.ReadWrite.All, Directory.ReadWrite.All, Group.ReadWrite.All - not suitable in our case)
  • and update using Update-MgDomainFederationConfiguration -DomainId 'our.federated.domain.com' (like contoso.com) -InternalDomainFederationId 'our-federation-id' -signingcertificate $variableWithCert
  • at first we've tested on -nextsigningcertificate, later on -signingcertificate
  • confirmation on Get-MgDomainFederationConfiguration -DomainId 'our.federated.domain.com' -InternalDomainFederatoinId 'our-federation-id' (pipe) Format-list - there we could confirmed that certificates were replaced
  • additional confirmation was on Teams on mobile devices - after logout and logon it was obious that it is working


Pay Attention!!! You must have BGA account without MFA (if you have enabled MFA) - probably You will have issues connecting to Azure after certificate replacement. Maybe You should open connection (powershell session) before any steps - just in case.