MaximumPC’s David Gerrold has written an article about what he’d like to see in future versions of Windows.
The title of this post is one suggestion I strongly support:
This requires a whole column, but the registry is a mess, filled with strange strings of numbers and letters, unknown identifiers, and codes for functions that have no discernable documentation. Tracking down problems in a system has become so difficult that even tech support gurus often end up stuck. (That’s another story, for another time.) And don’t even think about tweaking.
This is the worst part—every time you install something to your system, the registry grows like the zerg creep in Starcraft. But every time you delete a program, the detritus of that program is left behind, leaving the registry strewn with trash. So the registry grows and grows and your system slows and slows.
In the days before the registry, software (mostly) behaved itself. It stayed in its own folder. If you needed to move a program from one machine to another, you just copied the folder across.
If you must have a registry, how about this instead? Every program has a REG folder which includes all of its registry additions. When a program is uninstalled, the whole folder is deleted and the registry is rebuilt from scratch, checking all the REG folders in the Program Files folder? Installation and removal of software would be simplified.
It started with one user walking in to tell us his machine was rebooting over and over.
It ended with all our Windows XP SP3 computers infected. And by what? Well, McAfee’s DAT number 5958 thinks svchost.exe is infected and thus either deletes the file or continues to reboot the box.
The fix, if it hasn’t gotten to svchost yet, is: boot to safe mode, rename mcshield.exe, reboot, run Virus Console, pick Tools -> Rollback DAT, name back to mcshield, reboot (this according to a twitter feed).
Thanks for the unneeded work, McAfee. Epic Fail!
I understand the idea behind GUIDs and SIDs. What I don’t understand is why, with Group Policy Objects, I have no easy way to translate the GUID (in the sysvol) to the GPO to which it belongs.
Some searching took me to a vbscript included in the Window Server 2003 support tools, but honestly … Yet another frustration discovered!
Thank you, Microsoft.
(And thank you, Darren Mar-Elia, for your great GPMC PowerShell cmdlets.)
What can I say about Moskowitz? I think he may be the most interesting and weird geek in the world.
Here’s his latest tip newsletter/advertising campaign (I’ve done the hard work of stripping out the advertising campaign part—thank me later):
This "big question" comes up all the time. [Why the quotes?]
Why is a "policy" a "policy" ? [Quotes again?]
So, all the stuff Microsoft ships in the box in the Administrative Templates section is a "true policy." That means the GP-engine is involved in delivering the policy, AND removing the policy. [H’m, more quotes.]
Applications that are "policy enabled" at looking at these four potential registry keys, and, if present "do something." [OK, I’m getting really tired of these quotes.]
Those "proper policies keys" are: [Sigh.]
HKCU\software\policies.
HKCU\software\Microsoft\Windows\CurrentVersion\Policies.
HKLM\Software\policies.
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies.If an app is "coded" to look to look there.. wonderful! You have a "policy enabled" application. The Microsoft Office family is coded to look here. You deliver a policy setting to Office, it obeys. You remove it… it "un-obays." But very, very few other applications will work like this. [All right, that’s it. “Stop” “using” “quotes” “inappropriately!”]
If you want to try to control other applications, you could create a "custom ADM" or "Custom ADMX" template. Which is all fine, except those settings are still "unmanaged." If you delete the GPO, those settings are "tattooed" or "left behind" because the GP engine will deliver these settings, but doesn’t "clean up" when the policy settings are removed. [I give up.]
From a year back, I found a newsgroup posting about the problem I’ve been having. I emailed the poster to find out if he’d ever found a solution to the problem we shared: “No, I did not, and that self-recursive folder is still there.”
Which instantly reminded me of something I’d read about prostate cancer—more men will die with prostate cancer than from prostate cancer. That’s what Exchange Server is to me: prostate cancer. Just one of those things you live with.
With much gnashing of teeth, I’ve been trying to delete a Public Folder from my tree for the last year, each time I try I get this lovely message:
Just what exactly is this telling me?
Maybe I’m dumb.
That’s it. I’m just plainly dumb.
One of our OUs require their users’ INBOX content be permanently deleted every 30 days. So, how to do this in Exchange Server 2007?
According to Microsoft documentation, it’s easy as pie. They even have a cutesy little graphic showing the 6 steps one needs:
(Love that robot, don’t you?)
Except it doesn’t work or perhaps, in the interest of intellectual honesty, I should say I can’t figure out how to make such a supposedly simple process work!
When I still had to synapses to rub together, I was a Unix administrator.
And when I was a Unix admin, I was able to dynamically update my $path variable dynamically in the shell after I’d inserted a new directory. I wonder if the same thing is possible in Windows without having to log off and back on?
