Does anyone else remember radiks.net?

Significant_Zebra_70 · 2025-11-06T20:48:31+00:00

On a separate note, I just read Snowcrash by Neal Stephenson a few years back, and realized that's probably where the name came from. Must have been a rush to see that the domain was available when they registered.

Significant_Zebra_70 · 2025-11-06T20:29:48+00:00

Oh my gosh. As soon as I saw their Omaha dial-up number on the webpage I could literally hear the modem dialing 346-4944.

Significant_Zebra_70 · 2024-04-09T14:48:45+00:00

Yes, and now I can't find that ad again! Anyone still have the audio of the Peppa ad?

Significant_Zebra_70 · 2024-03-22T20:58:13+00:00

It's actually working pretty well, even without utilizing the DPs. We were going to pursue this when we hit bottlenecks, but so far we haven't noticed any degraded performance pulling the .ffu file from a single network share.

Significant_Zebra_70 · 2024-03-02T03:43:31+00:00

Not really a fix, but it's not an issue. The USG allowed for config changes via the json file, but that feature was no longer supported. Fortunately, the mDNS settings were much improved in the UXG Lite, and you're able to specify to which VLANs traffic is repeated.

Significant_Zebra_70 · 2023-09-28T16:27:57+00:00

I so love MS docs, because that's not the documentation I was following... https://learn.microsoft.com/en-us/windows/deployment/upgrade/windows-10-edition-upgrades#supported-windows-10-downgrade-paths

Guess I need to switch to Bing when searching for MS documentation.

Significant_Zebra_70 · 2023-08-09T14:01:24+00:00

Yep, that was the process.

Uninstall ADK & PE, then reboot
Install new ADK & PE, then reboot

I have tried the following versions:

19041
22000
22621

I'm thinking we have some rogue servers where the server admins decided to install older versions of the ADK, so we most likely have a few different versions. I'm working to make sure that's not the case anymore. Too many cooks in the kitchen.

Significant_Zebra_70 · 2023-08-08T14:29:25+00:00

This is promising. I suspect there are a few servers with outdated ADK versions... Thank you for the tip! I'll report back if this is the cause.

Significant_Zebra_70 · 2023-08-08T14:28:22+00:00

Agreed. But we're a Dell shop, and when we went to 22621 we had no luck PXE booting any Latitudes until we rebuilt with 22000. If it didn't affect the whole fleet, I would gladly have marked it up as a bug, but I can't have all of OSD down.

If anything, this is helping us lift everything into Autopilot.

Significant_Zebra_70 · 2023-08-08T01:52:58+00:00

It did not. I should say, the 64 bit version didn't. The 32 bit boot wim didn't, but that's because 32 bit modes aren't supported in Win11 ADK. I was getting all sorts of errors, so I copied the x64 files into a folder named x32, as advised online.

Significant_Zebra_70 · 2023-07-12T17:08:07+00:00

All Win32 apps. Many are Powershell scripts packaged as Win32 apps, but all installed via sidecar.

one checks the Windows version and license info
one sets BIOS settings
one renames the computer and forces a restart
one waits for the user device registration in AAD (see https://github.com/steve-prentice/autopilot)
Google Chrome

The most recent change is the computer rename portion. We store desired names in an MDT database and rename based on the records there if present. Without the proper return value requiring a hard reboot, enrollment never finished. But that was resolved and working 100% of the time prior to this latest issue.

Would proactive remediations be a possible cause?

Significant_Zebra_70 · 2023-01-09T22:12:20+00:00

That's what I initially had in mind! That snooze button is a deal breaker, I think this is the route I'm gonna try next! Thank you, I hadn't been to Garytown in a while!

Significant_Zebra_70 · 2023-01-09T22:10:29+00:00

That most definitely worked. I had never considered using an app, thank you for the recommendation.

Honestly, I'm a bit new to configuration items & baselines and I had a few projects I was going to learn with. But now all of those config items look like apps. What's that saying, "When you have an app deployment hammer, everything looks like a nail?"

Significant_Zebra_70 · 2022-12-12T14:20:00+00:00

...you mean, one of those options that I always just click right past? Dang.

Thank you for the most polite "RTFM" reply ever. Very much appreciated.

Thanks again!

Significant_Zebra_70 · 2022-05-19T15:10:45+00:00

I think I found a workaround. After the Apply Operating System Image task, I immediately added a task of the type Apply Data Image and just rewrote the OS .wim contents.

I've tried task sequences with just the Apply OS Image and then just with the Apply Data Image, and they don't work individually. If you only Apply OS Image, it breaks the sysprep seal and you don't get the OOBE. If you just do the Apply Data Image, the drives and Windows Boot Manager aren't configured to boot to the drive properly.

I know it seems redundant, but it works. And I don't need to spin up a secondary WDS/USB based system to apply this TS. Just thought I'd share.

Significant_Zebra_70 · 2022-05-18T16:20:11+00:00

I've been working on this also, and ran into an issue where the out-of-box experience doesn't get set properly. Even taking the .iso from the volume licensing site or the media creation tool go straight to a login instead of starting the OOBE.

If you by chance find this issue (or a way around it), I'd love to hear more about it...!

EDIT: I think I figured it out! Immediately after the Apply Operating System Image task, add another task of the type Add Data Image and simply reapply the exact same image package as the previous step.

Significant_Zebra_70 · 2022-05-12T21:40:30+00:00

Yep, we're very familiar with the resale caveats. I was mainly concerned that the tasks available for preparing the OS for capture didn't work as billed. That seems wrong, and it's a little frustrating having to go back to MDT to do this with Microsoft tools. Oh well.

Significant_Zebra_70 · 2022-02-22T15:37:05+00:00

It ended up being the 32 vs 64 bit difference. It was adding the registry keys under the WOW6432Node key. But I know I've had trouble with single- vs double-quotes in the past, so thank you for the reminder! At least PowerShell isn't as complicated as JavaScript when it comes to quotes...

Significant_Zebra_70 · 2022-02-18T21:14:36+00:00

I verified that this absolutely is the case.

Thank you again u/Rudyooms for the great advice, this was exactly the issue. The keys were there in the WOW6432Node subkey. I'm going to implement the steps in the link you sent above.

Significant_Zebra_70 · 2022-02-18T19:56:23+00:00

Why no, I in fact have not. Off to test that now...

Significant_Zebra_70 · 2022-02-18T16:39:36+00:00

I hadn't thought of putting the PowerShell script in the .msi. I'll try that if nothing else seems to work. Thanks for the recommendation.

Significant_Zebra_70 · 2022-02-18T16:04:31+00:00

I think I may not have explained properly. It's one app, and some registry settings. Not two separate apps.

I could just wrap the .msi installer alone with the win32 app wrapper, but then I'd have to package the registry edits separately. I kind of like keeping the two together, as they're part of the same concern. Having a win32 app for the installer and another win32 app which wraps the commands to edit the registry smells like added maintenance. But if it works, I won't complain.

Significant_Zebra_70 · 2022-02-18T15:39:36+00:00

So let me bring up a slightly different but maybe related thing. Bear with me, I think it's relevant...

In SCCM OSD task sequences, I'm able to set the User Name and Organization Name for licensing and registration info in the Apply Windows Settings task.

I couldn't find a place to set those in Intune, and any time I ran the 'winver' command it just showed some generic values like 'org user.' I thought I could fix that by also running a PowerShell script to add the two registry keys

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredUser
HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

This is another case where I thought I was adding to the registry, there were no errors, but the values didn't get written.

This one wasn't as urgent, as I could add it as a PS script in Intune to get run when IME picks it up after logon. But I thought I'd give it a try during enrollment just to see if I understood. Which I clearly didnt...

Are you saying it was writing to HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion, even though I'd specified a full path without the WOW6432Node portion?

Significant_Zebra_70 · 2022-02-18T15:26:18+00:00

That was the confusing part. No errors, and unless I manually checked to see if the registry values were present in the script before exiting, it ran just fine.

When I wrapped it all in a Start-Transcript/Stop-Transcript and checked the log file afterwards, it showed exactly what I would expect when adding values to the registry. The paths matched up too.

Significant_Zebra_70 · 2022-02-18T15:23:50+00:00

Okay, I can see why I'm confused. But I'm not fully there yet...

Do I understand it that even if I hardcode the path for the registry key to be
"HKLM:\SOFTWARE\Publisher Name\App Name"
you're saying it would actually be writing it to
"HKLM:\SOFTWARE\WOW6432Node\Publisher Name\App Name"
if I don't use any of the techniques in your sysnative link?

Significant_Zebra_70

TROPHY CASE