Forum Widgets
Latest Discussions
Demote a 2019 server - problem
I want to demote one of our 2 DC's in preparation for server replacement. Replication between the two works fine and both DNS's are synced and up-2-date. But when I run the wizard, I need to check that "This is the last DNS server" which is not true. If not, I can't proceed to the next step (Next becomes greyed out). As an experiment, I did this last week and it resulted in a domain where no client could logon, and no file shares was working on the remaining DC/File server. So I restored both backups to get back in business. I do not want to repeat this again. I have browsed the complete DNS tree for the forward zone and everything looks fine to me (SRV, NS etc records)
dbgeng.h: GetTotalNumberThreads Returns Incorrect Thread Count (According to DAC)
When writing custom extensions for Windbg to analyse user-mode crash dumps(using the IDebugSystemObjects4interface provided by dbgeng.h), IDebugSystemObjects4-->GetTotalNumberThreads returns a smaller number than Strike/SOS. There is no documentation about whereIDebugSystemObjects4 gets the thread count from -- it just states: The GetTotalNumberThreads method returns the total number of threads for all the processes in the current target, in addition to the largest number of threads in any process for the current target. (Emphasis mine.) Below is an example output from Windbg: 0:000> <Custom Windbg Extension Method Here> Getting IDebugSymbols... Getting IDebugSystemObjects... Getting GetTotalNumberThreads... Total Threads: 581 Largest Process: 581 Frames: 32 0:000> !threads ThreadCount: 587 UnstartedThread: 0 BackgroundThread: 26 PendingThread: 0 DeadThread: 47 Hosted Runtime: no Note that theIDebugSystemObjects4-->GetTotalNumberThreads method is returning 581 threads but Strike/SOS is returning 587. For what it's worth, Strike/SOS gets this data from the DAC -- which is, presumably, a different source thanIDebugSystemObjects4 is getting the thread count from. Is this a bug in dbgeng.h? If not, is it becauseIDebugSystemObjects4 ignores finaliser threads; whereas those are not ignored when committed to the DAC? Also, sorry if this is the wrong place for this, I was thinking Windows SDK-related questions/bugs would fall under "Windows OS Platform".
Questions about Windows Server 2008 SP2 and Windows Server 2008 R2 SP1 support plans.
I have known that all the supports of Windows Server 2008 SP2 and Windows Server 2008 R2 SP1 has ended at Janauary 9th, 2024, the date where mentioned in Microsoft Lifecycle Policy. But I have found some updateswhich released after Janauary 9th, 2024,in Microsoft Update Catalog, and these updates will provide to these Operating System which have 4 years ESU license. So why does Windows Server 2008 SP2 and Windows Server 2008 R2 SP1 still can receive these updates after Janauary 9th, 2024? Does these Operating System has any additional support plans after that day? When will these OS doesn't receive any updates?
Automatic installation of Roots Updates
You can use the registry parameter to redirect the source of root certificate updates: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate "RootDirURL"="d:\......." Is it possible to automatically distribute certificates of intermediate certification authorities in this way?
Invalid requesting-user-name value after system reboot (IPP Everywhere)
When I add a IPP Printer, it works fine until I restart OS, after system reboot the requesting-user-name contains WORKGROUP\VM132786998$ so it's domain\computerName$. And the user cannot be correctly recognized. Steps to reproduce it: 1. Add IPP printer 2. Print Test page 3. Restart system 4. Print Test page Current result if inspecting by Wireshark: at point 2. requesting-user-name contains correct "Administrator" value at point 4. requesting-user-name contains incorrect "workgroup\VM132786998$ Expected result: in both cases correct value Administrator must be present. Currently only restart print spooler or recreating printer solves the issue. (See attached wireshark captures before and after print spooler restart) Note: The issue is not reproducible in build 22H2 22621.3447. I'm able to reproduce it in 23H2 22635.4076. Same error is observed here (comment from Douglas Kosovic): https://learn.microsoft.com/en-us/answers/questions/1428508/ipp-everywhere-ipp-2-0-server-basic-authentication Attached screenshots from wireshark captures when it's happening and after restarting Print Spooler.
