TaskScheduler error 0x800710e0

0x800710e0 - meaning - task not launched do to missed start time - reason? Server restarted - by updating team.

ADSIEdit 0x8000500d property not found

Some LDAP instance - connection through AdsiEdit - it is not a problem with authentication - my ldap account allowing me to connect. Problem with encryption? I don't think so, so what the hell it is?

Error replication - tombstone lifetime exceeded

I've got small lab - domain controllers and the whole lab was run at 2018, so I've received error, that tombstone lifetime is exceeded.

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Allow Replication With Divergent and Corrupt Partner" /t REG_DWORD /d 1 /f

RC4 depreciation in 2026

According to Microsoft document related to CVE-2026-20833 in July by default kerberos tickets by default will be created with AES tokens.

double dots name prevent synchronization group to Azure

case: on-premise user or group with two consecutive dots in name like "Group..1"; AADC synchronization rule with simply flow mailnickname (direct) alias

error: wrong mailnickname (but mailnickname is empty in the source directory)

TLS SSL SNI

SNI - server name indicator - part of TLS standard - similar to host header

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.