> Add a bigger disk. Share some files to your old Windows machines. Learn how old Active Directory worked. Set up Exchange and get some mail going.
Active Directory was in Windows 2000, NT4 has a different domain technology. If you want to play with old Windows Server stuff, Windows 2000 would be a better, more coherent option, compatible with more modern software.
I ran a lot of Exchange 4.0 thru 5.5 on NT 4.0 and Exchange 2000 on Windows 2000 and 2003 back in the day. I can't say I miss any of that software (except, maybe, some faint happy remembrance of Windows Server 2003). Windows 2000 and newer are infinitely more useful and less quirky the prior NT versions (coherent OS servicing strategy, fewer reboots after settings changes, plug 'n play support).
I suppose there's an argument to be made for trying that stuff out to see why the newer stuff is better. In a homelab, though, you're never going to get to the scale to see why NT 4.0 domains were a pain point. Likewise, you probably won't be max'ing out an Exchange EDB size, or feeling the I/O pain that came w/ trying to sling content from a 50GB Exchange Information Store thru a 32-bit OS.
There definitely is an "ah, ha!" moment to be had looking first at the NT 4.0 Domain system, then at an Exchange Directory Service, and thinking "What if my Windows Domain could be like this?" (This was the genesis of Active Directory.)
My only "critique" of the article is the lack of SMP (multi-core) enablement
NT 4 did support rudimentary multi-processor (Symmetric Multi-Processor) systems back in the day. But it seems to lack the `HLT` instruction in the SMP enabled HAL
This means an NT 4 VM will always operate at 100% CPU usage even if it's simply idling.
Back in the 2000's when folks were slowly migrating NT 4 workloads to VMware, enterprising users took it upon themselves to patch the NT4 SMP HAL to fix this. But in my own testing that doesn't seem to work and results in a blue screen of death on boot.
There's probably a way to do it under QEMU/Proxmox. But I haven't dug deep enough to figure it out myself
If anyone can find the archive link to the original, I believe there was discussion in the comments about "why not exclude it for specific hardware only" and the risk of false negatives was deemed too high
> migrating NT 4 workloads to VMware, … patch the NT4 SMP HAL to [issue HTL]. But in my own testing that doesn't seem to work and results in a blue screen of death on boot.
IIRC some drivers were very unhappy with this, IIRC something about interrupts waking a processor that then started a transfer, while something running on the other was already waiting for a transfer to complete. For some (virtual) hardware combinations it worked smoothly but others were very unreliable.
We just switched to the single professor HAL as that still performed as well as the older CPUs when virtualizing on newer kit and was much more reliably stable.
Wow that NT era weave logo triggered a lot of memories. In particular Windows Back Office (which later became SBS). Many evenings spent fixing SMS, Mail, and ISA.
There is a lot to be said for on prem that the cloud era marketing departments have erased. I seriously miss the on prem first mindset. It’s not clear at all to me if there is a universal best/winner now.For example: I regularly hit issues with Entra where there are feature gaps vs AD such as MemberOf. But as a counter, I have no love lost for roaming profiles. You could probably debate it for weeks.
I'm not sure how it holds up. This was the very last generation of big tech books about Windows Server that were not aligned with a test curriculum. I honestly don't know if that's a good thing; the standardized tests at least made sure (I hope) that the information was accurate and that the important topics were covered. Whereas I started with a blank sheet of paper. Wrote whatever I could figure out and get working.
Very much pre-Active Directory; in my day job at the time we ran a Banyan Vines network, because the directory is the primary service.
I'm proud of the chapter on Macintosh clients, as it was a good piece of tech at the time and no one else talked about it much.
I couldn't find a way to contact the author, but in case he's reading this or anyone knows his contact information: I'd like to subscribe to your blog, but your RSS feed is currently broken.
If you remove the "blog." subdomain and go to https://pipetogrep.org/ you are greeted by a typical "about me" page. It includes a link back to the blog, as well as a mailto link, and links to GitHub and LinkedIn profiles.
I really like NT 4.0 as well. In my experience the stability varied based on hardware and driver support, though. I tried running NT 4.0 on a "relatively fast" K6-3+ system with GeForce 2 and AWE64 but had weird issues, like sound stuttering in games that the same hardware runs fine under Win98 and 2K. I had endless trouble getting it installed too, I ended up installing in 86Box then imaging onto the host. I could fairly easily get it to BSOD by doing multimedia type work on it. Really though, not a fault of NT 4.0 so much as I probably didn't have the ideal drivers or hardware combo.
But on a fast 486 system, a bit older than NT 4.0 was really designed for, it ran flawlessly and made the dusty hardware feel very competent and modern - lots of common software runs fine on NT 4.0 including Winamp and specially compiled versions of modern PuTTY. It's probably my favorite OS for a DX4-100.
The main reason for preferring a newer version of Windows has generally been hardware compatibility. But when virtualising (or emulating), this is far less important as compatibility is usually scaffolded by emulated hardware and/or backported drivers.
When your requirements call for an old version of Windows, generally you have a specific piece of software you want to run, so start by choosing the version most widely used at the time, which sometimes isn't the latest version. And you should always experiment, because there are thousands of things which contribute to stability. Newer (or older) version of Windows could be better or worse, depending on your specific case.
Regardless which version you pick, treat them as a security risk and (if you're in a serious production environment) avoid giving them unrestricted access to your local network or unrestricted access to the wider internet.
Not really. I started using both around the time 2000 Server appeared and I preferred 2000 because it was easier to use on the hardware that I had, which was some Intel multiprocessor servers (made by Intel, not just the CPUs). The Active Directory of Windows 2000 was a pain point to support, but otherwise 2000 was "a better NT" for me. I don't remember the details, but I think the software compatibility was also better with 2000, I mean the software written for Win 98 and Win ME.
Was the choice of Windows NT 4 Server over the Workstation version intentional? I can't recall the specifics, but I remember the Workstation version being way more lightweight and easier to setup.
Quoted in PC WeekOnline ("Microsoft: 'significant differences' between NTS, NTW", Norvin Leach, September 10):
Roberts acknowledged that NTS and NTW are included in the same binary file. It was easier to build and test them that way, he said. The setting in the Registry, he said, triggers 48 changes to the kernel. These changes cascade down to 700 additional settings in software outside the kernel.
The server edition had DHCP, WINS and DNS servers included and also could create Windows Domains (act as domain controller). All optional, but useful at that time as there were not many options.
Readit News
Active Directory was in Windows 2000, NT4 has a different domain technology. If you want to play with old Windows Server stuff, Windows 2000 would be a better, more coherent option, compatible with more modern software.
I ran a lot of Exchange 4.0 thru 5.5 on NT 4.0 and Exchange 2000 on Windows 2000 and 2003 back in the day. I can't say I miss any of that software (except, maybe, some faint happy remembrance of Windows Server 2003). Windows 2000 and newer are infinitely more useful and less quirky the prior NT versions (coherent OS servicing strategy, fewer reboots after settings changes, plug 'n play support).
I suppose there's an argument to be made for trying that stuff out to see why the newer stuff is better. In a homelab, though, you're never going to get to the scale to see why NT 4.0 domains were a pain point. Likewise, you probably won't be max'ing out an Exchange EDB size, or feeling the I/O pain that came w/ trying to sling content from a 50GB Exchange Information Store thru a 32-bit OS.
There definitely is an "ah, ha!" moment to be had looking first at the NT 4.0 Domain system, then at an Exchange Directory Service, and thinking "What if my Windows Domain could be like this?" (This was the genesis of Active Directory.)
NT 4 did support rudimentary multi-processor (Symmetric Multi-Processor) systems back in the day. But it seems to lack the `HLT` instruction in the SMP enabled HAL
This means an NT 4 VM will always operate at 100% CPU usage even if it's simply idling.
Back in the 2000's when folks were slowly migrating NT 4 workloads to VMware, enterprising users took it upon themselves to patch the NT4 SMP HAL to fix this. But in my own testing that doesn't seem to work and results in a blue screen of death on boot.
There's probably a way to do it under QEMU/Proxmox. But I haven't dug deep enough to figure it out myself
Maybe one of the same utilities commonly used to work around this same issue on Windows 95?
Amn Refrigerator (formerly AmnHLT) — not relevant for NT because it uses a VxD driver, but it's my favorite for Windows 95 so I'm linking it here for completeness: https://web.archive.org/web/20010331184312/http://www.amn.ru...
KCPUCooler: https://web.archive.org/web/20010607173439/http://www.kt2k.c...
CpuIdle: https://web.archive.org/web/20030925110541/http://www.cpuidl...
Waterfall and/or Rain from Leading Wintech (can't find the original URL): https://vetusware.com/manufacturer/Leading%20Wintech/?author...
VCool or CPUCooL might be the ones to try because they're the only ones that seem to explicitly mention supporting NT:
“VCool now utilizes its own driver on NT, W2K, XP: vcool.sys” https://web.archive.org/web/20041205132318/http://vcool.occl...
“CPU Cooling under Windows 95 / 98 / NT / 2000 (Watch Wintop !)” https://web.archive.org/web/20041211214000/http://www.cpufsb...
If anyone can find the archive link to the original, I believe there was discussion in the comments about "why not exclude it for specific hardware only" and the risk of false negatives was deemed too high
Threads would jump around cores, killing most performance gains by using multiple threads.
The workaround was the typical getting the amount of CPUs and park each thread on their own one, this alone made quite an observable improvement.
I think by Windows Server 2003, this scheduler issue was already sorted out.
IIRC some drivers were very unhappy with this, IIRC something about interrupts waking a processor that then started a transfer, while something running on the other was already waiting for a transfer to complete. For some (virtual) hardware combinations it worked smoothly but others were very unreliable.
We just switched to the single professor HAL as that still performed as well as the older CPUs when virtualizing on newer kit and was much more reliably stable.
There is a lot to be said for on prem that the cloud era marketing departments have erased. I seriously miss the on prem first mindset. It’s not clear at all to me if there is a universal best/winner now.For example: I regularly hit issues with Entra where there are feature gaps vs AD such as MemberOf. But as a counter, I have no love lost for roaming profiles. You could probably debate it for weeks.
https://archive.org/details/windowsntserver400cowa/page/n9/m...
I'm not sure how it holds up. This was the very last generation of big tech books about Windows Server that were not aligned with a test curriculum. I honestly don't know if that's a good thing; the standardized tests at least made sure (I hope) that the information was accurate and that the important topics were covered. Whereas I started with a blank sheet of paper. Wrote whatever I could figure out and get working.
Very much pre-Active Directory; in my day job at the time we ran a Banyan Vines network, because the directory is the primary service.
I'm proud of the chapter on Macintosh clients, as it was a good piece of tech at the time and no one else talked about it much.
If you remove the "blog." subdomain and go to https://pipetogrep.org/ you are greeted by a typical "about me" page. It includes a link back to the blog, as well as a mailto link, and links to GitHub and LinkedIn profiles.
Despite my own experience with Windows ends with XP, NT 4 was always my favourite version.
But on a fast 486 system, a bit older than NT 4.0 was really designed for, it ran flawlessly and made the dusty hardware feel very competent and modern - lots of common software runs fine on NT 4.0 including Winamp and specially compiled versions of modern PuTTY. It's probably my favorite OS for a DX4-100.
When your requirements call for an old version of Windows, generally you have a specific piece of software you want to run, so start by choosing the version most widely used at the time, which sometimes isn't the latest version. And you should always experiment, because there are thousands of things which contribute to stability. Newer (or older) version of Windows could be better or worse, depending on your specific case.
Regardless which version you pick, treat them as a security risk and (if you're in a serious production environment) avoid giving them unrestricted access to your local network or unrestricted access to the wider internet.
Almost surely the whole article applies identically to Workstation
Roberts acknowledged that NTS and NTW are included in the same binary file. It was easier to build and test them that way, he said. The setting in the Registry, he said, triggers 48 changes to the kernel. These changes cascade down to 700 additional settings in software outside the kernel.
[1] I don’t remember the details but often workstation had soft limits compared to server. There were hexedit ways around them.