Monthly archives: October 2007
Here's a great example of why I hate the GPL:
[Ebay Item Listing Link]
If that link is broken, just search on Ebay for Microsoft Office and you are bound to run into dozens of items listed actually selling OpenOffice (free, OpenSource, basic "office" package). Now, mind you, I'm not against "selling free software" in all cases because, afterall, CDs cost money to burn, but selling a download link where the proceeds clearly are not going to the person paying bandwidth bills? The download link is FREELY ("as in beer" as the kids say) and EASILY found on the google!
These jerks on Ebay are CLEARLY exploiting those that are looking specifically for good deals on Microsoft Office (it shows up in a "Microsoft Office" search afterall because of a clever title) and see this item and think, "wow, great, where do I sign up?" What these poor consumers don't realize is that they are being swindled out of a few bucks.
This seller is NOT selling a CD burned with OpenOffice (for which $4-5 is fair). He/she is selling a download link -- the thing you find in two seconds on the google! The problem is the target consumers are not particularly savvy and don't KNOW they can find this application for free with a simple search.
Now this example of $4 is not the most egregious offense. I've actually seen completed items going for up to $80 on Ebay. Unfortunately, Ebay has purged the history that far back (this was a couple months ago when somebody emailed me the completed listing). It seems "competition" has forced the link prices to go down since other jackasses have now thought it's a good way to make an easy buck off some poor unsavvy chaps. Jerks. And, no, market pressure didn't resolve this. Four dollars is still too much to pay for something that is free. Especially when all you are selling is the knowledge of the link to download it! Remember that the authors and distributors of OpenOffice are not being compensated here.
And this crap is all perfectly legal under the terms of the GPL. So it's not Ebay's fault.
Good job, FSF. Software freedom is on the march.
So I thought I'd try to get the word out about the wonderful and free RD Tabs by submitting it to a few more software download sites. I hit TUCOWS. (Remember when they were popular? You know, back in '98?) Anyway, I finished the submission and this is the message I got.
There are 8493 program adds currently in the queue.
Estimated time until your software is evaluated: 1701 days.
To expedite the process, please choose one of the following options:
Whoa, there, horsey! 1701 days? That's like over FOUR years! No wonder most of the software on there is so out of date... And I thought download.com's one month turn around time was bad (they JUST approved RD Tabs 2.0.8). Of course, as you can see up there, I can expedite the process by PAYING them. Like free software generates dispoable income. I mean I don't expect them to jump over hurdles here, but 4.5 YEARS? 90 days is more reasonable.
So I thought about it for a minute and realized they at 1701 days, they are only processing 4-5 programs PER DAY. Holy smokes! How many people work there? I mean I could do that in an hour on my own.
What a racket... I won't be complaining about download.com taking five weeks any more (and here I thought that was sluggish). Apparently that's incredibly good turn-around time for no payment... Even if they do add typos into the description that I didn't type in. (Haven't they heard of cut'n'paste?)
I ran into an issue the other day where we had two servers in an isolated domain that were steadily losing disk space to an unknown cause. It turns out the cause was Forefront Client Security. The reason? Forefront's history kept accumulating events at a rate of approximately 120 events every five minutes! The history folder grew to about 2.5 GB in just over three weeks and had tens to hundreds of thousands of files (not sure how many exactly as Explorer would crash before I could get a count). Why? Group Policy was set to "Process even if Group Policy object have not changed" and so the firewall rules set up policy were being reevaluated by FCS every five minutes! Not a bug, persay, but definitely something that should be addressed in future versions of FCS. Anyway, here's a link to the newsgroup article I posted on TechNet. No responses yet at the time of this blog post, but hopefully somebody at Microsoft will chime in on this issue. http://forums.microsoft.com/ForeFront/ShowPost.aspx?PostID=2258749&SiteID=41&mode=1
The other day, I was setting up my very first corporate Vista machine. It was a new laptop with Vista Business pre-installed that was to become the first live Vista machine on our corporate network. An exciting day it was. ... Okay, actually it was a pretty frustrating day because this machine was NOT cooperating. I had deployed test machines in our sandbox OU and thought I had ironed out all the problems, but not so... This laptop had one glaring horrible problem: I could not log on as a domain admin!
Now that's a big problem...
I was perfectly able, mind you, to log on as my normal account and then elevate to a domain admin when needed, but the domain admin logon itself failed. All I would get is a lonely empty black screen. It's as if Windows Explorer forgot all about me. How depressing! I named this experience the "Black Screen of Purgatory."
So what was the problem?
I went back to my regular logon, fired up Event Viewer and scoured the logs. This is the event that I found every time I tried to logon interactively as a domain admin...
Log Name: Application
Event ID: 4006
The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:\Windows\system32\userinit.exe.
Interesting, eh? Winlogon was actually failing to spawn a process. I wonder why? It runs as SYSTEM, afterall, even in Vista. SYSTEM has full control over most everything.
I scoured the google and found only a few pages related to Vista and only one related to Vista and domain admins logging on. The culprit? UAC.
Oh that blessed security feature we all love to hate! (--or is it hate to love?) Apparently, UAC was trying to open an elevation prompt during logon. Well, no interactive session has yet been established (that's the job of Winlogon and userinit.exe afterall) so the UAC elevation prompt just gets lost in the ethos of the Black Screen of Purgatory.
Luckily, if you press Ctrl+Alt+Del, you still get the security menu. No, TaskMgr won't run. But you can log off without powering down your computer.
The article that discovered UAC was the culprit also noted that turning off UAC fixed this problem. Well, of course disabling a security feature and preventing it from doing it's job will make things work (just ask the developers at the company I work for), but that's the cheap way out. I want to figure out WHY this is happening and fix it.
So I started doing some tests. First, I tried a local administrator account. That works! Wow, domain admins don't, but local admins do. Interesting. So then I guessed that maybe a GPO was the problem, so I pulled the computer out of it's home OU and put it into a test OU which blocks all policies. I rebooted.
I was able to log on as a domain admin. Very interesting! It was a GPO. But which one?
After gradually adding and enabling all applicable policies, I found the culprit: Restricted Groups.
That's an unusual, culprit, isn't it?
In order to keep local groups clean, I use Restricted Groups to prevent unauthorized additions to the Users and Administrators groups on workstations. In XP, it was sufficient for Domain Admins to be members of only the Administrators local group to gain full access to the machine. This is not the case in Vista. For some reason, if Domain Admins are not ALSO in the Users local group, they cannot logon due to UAC trying to request an elevation prompt at pre-logon. Apparently, permissions are set okay from a traditional standpoint (disabling UAC "fixes" this issue), but UAC doesn't like tradition. The reason you don't commonly see this issue on Vista machines is because in Vista, the built-in principle INTERACTIVE is normally automatically a member of the Users local group, but I had overwritten the Users local group with my own members by policy. Why do I do this? Because I don't want, for example, role accounts getting interactive sessions on workstations. I'm just paranoid like that.
I also noticed that in Vista, Local Service and Network Service are automatically members of the Users local group, so I suggest also adding those to your Vista Restricted Groups policy to prevent future weirdness.
Mystery solved and case closed.