Sonnet from the Vulcan: Omicron Ceti Three

by Shirley Meech

I thought the memory of you was gone—
I thought it buried underneath the years.
But now, it rises, bright as Vulcan dawn,
And I remember you, and Earth, and tears.

Your tears were falling like the rains of Earth;
You were the storms and roses of Earth's spring.
You could not know that, almost from my birth
The rites of Vulcan bound me to T'Pring.

I could not break those ties; I had no choice—
Returned to space, left you and Earth behind.
But still I heard the echo of your voice,
Found the rain and wind and roses in my mind.

You told me that you loved me, and you cried.
I said I had no feelings. And I lied.

***
Originally published in Star Trek: The New Voyages
Bantam Books 1976

DC not replicating and DFSR Error 4012

I finally got a second domain controller added to my [production] network, and couldn't get the domain to replicate. The second DC was missing NETLOGON and SYSVOL, and clients were still authenticating against the first DC. I always thought additional DC is supposed to automatically replicate, but apparently not.

I followed Microsoft's troubleshooting guide but didn't think that I needed to go through all that since I'm not actually having a failure condition. Fortunately, event log came to the rescue. I discovered that my DC has not been disconnected from other partners for 457 days, which is the exact number of days since I brought this DC online.

Since there are no other partners to replicate, I thought this must definitionly be a warning condition and not a failure condition. Searching for the error message I discovered there's content freshness protection in DFSR and the default value is 60 days like it says in the event log. So I set the MaxOfflineTimeInDays to 458, restarted the DFSR service, and suddenly the second DC came online, and everyone lived happily ever after.

Join Windows XP to Windows Server 2019 domain

Unfortunately, I still have Windows XP clients, and I couldn't figure out how to join them to the Windows Server 2019 domain. The error was a simple "An internal error occurred." with nothing in the event logs. I thought the error could be related to SMB1, but it wasn't. I also thought it could be because it's simply not supported, but from Google searches it appears to be possible. It also didn't seem to be related to the domain functional level.

After months and months of hair pulling, I figured it out thanks to a seemingly unrelated blog post. The post talks about problems joining 2008 R2 domains. I had no issues with 2008 R2 since before the upgrade that was what we were using. But installing KB969442 instantly allowed me to join the XP systems to the 2019 domain (functional level is 2016 of course). Funnily enough the post was from nine years ago to the day. The blog looks abandoned like mine but I left a message there thanking the owner.

Now I can continue to use unsupported OS's.

Your connection isn't private

History repeats itself. Once again multiple websites are blocked here in Thailand. Even HTTPS sites get redirected to a local unsecure site with this image. No leaves this time, just a simple menacing message. Hope the violence doesn't get too bad this time.

Windows update install now

 

The computers in my domain have Windows Update configured by GPO and normally should automatically download and install cumulative updates. (I'm lazy and I use WUfB.) However, recently I discovered that some computers get stuck with Status: Pending install and the button saying "Install now" and will not continue without user intervention.

We use PDQ Inventory and Deploy in our environment, so I figured I could probably send a command to these computers to force the install. Turns out this is a lot more difficult than it seemed at first. Google search suggests using wuauclt and usoclient, but these commands don't seem to do anything. Further research suggests that these commands have been deprecated in the latest Windows 10 versions. I then tried various PowerShell modules and WMIC commands and nothing worked. I think one reason is that Windows 10 computers in a regular enterprise environment expect to be shutdown and awakened regularly for updates. Unfortunately a lot of my computers have to be operational 24-hours without a fixed downtime, and then some computers are laptop computers that don't want to be awakened at night.

Turns out there's a really simple solution to all this. PDQ Deploy has built-in packages for Windows Updates. Applying the Windows Update package seemingly does nothing, but at the next reboot, the pending updates get installed automatically without user intervention, then users simply need to choose the update option next time they shutdown or restart. I looked in the PDQ Deploy package and all it does is stop the Windows Update service, install the latest servicing stack update, install the cumulative update, then restart the Windows Update service. Magic!

Sysadmin Day 2020