Administrative


I have been using the Windows Media Center Edition (MCE) for several years and have had great success with it. My home built Home Theater PC (HTPC) was beefy and decked out (for the time). All in all it was nice. Then came our plasma HDTV which changed everything. I had to upgrade from 2 internal video capture cards to use 2 Comcast HD set top boxes. But to get HD out of it I had to use 1394, bubble gum and baling wire. It was as hacky as it got, but it worked — usually.

Several years later I finally broke down and purchased a Vista MCE. It’s a very nice Velocity Micro box and decked out with 2 internal cablecard tuners and a beefy video card. Again, it is very nice. Very nice, until I tried using my XBox 360 as a Media Extender.Long ago I purchased a Linksys media center extender so that I could watch news, movies and, of course, Law & Order while on the elliptical machine. The problem was that once we started recording HD I was screwed. The Linksys not only could not handle the bandwidth required for HD over its wireless network, but the machine itself couldn’t handle it even if it was wired directly with a cat 5 cable. Sad, very, very sad.

This is not really a Win32 Perl related blog entry, but a problem that my team recently experienced. I am adding this to our blog site with the hope that someone else experiencing the same problem may find it useful and (hopefully) save them some time troubleshooting.

Recently I ran into quite the system administrator emergency. Our Active Directory network started acting flaky. How odd it was that our servers were unable to talk with each other. Client machines were not able to boot onto the network. Attempts to access resources were confronted with ungodly long blocking wait times only to eventually fail.

Applications and services that normally execute flawlessly were suddenly cast into a bottomless pit of error massages such as:

There are currently no logon servers available to service the logon request

and

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Of course the big question was why were there no logon servers available and why was there an attempt to compromise security? Needless to say it took several hours until my team could locate the root cause of the problem. Of course finding the cause is one thing, fixing it and understanding how the problem occurred is another.

So this entry isn’t about Perl but it is about a distant cousin, PHP, and the WordPress blogging software (v2.1+) spell checking bug that results in the notorious message:

Could not execute AJAX call, server didn’t return valid a XML

First let me start by saying that WordPress is a tremendous piece of software. I only have good things to say about it. Now that that is out of the way…

In WordPress v2.1+ there is a WYSIWYG option for writing posts, pages and comments. It isn’t full featured, but it is easy to use and provides the basics. It even includes a spell checker (which I am using as I write this). It is this spell checker that is causing so many people problems. When many people try to use the spell checker they receive the error message cited above. WordPress.org has a thread on this: http://wordpress.org/support/topic/101689

Having run into the same problem I decided to spend a couple of hours tracking down the problem and I can say that I have fixed it (on my system at least). My platform is running Windows Server 2003 with IIS and WordPress v2.2. I have patched my system and spell checker is working like a champ.

Along with Vista’s UAC security infrastructure Microsoft implemented something very clever, but has caused administrators and Perl coders frustration: User File and Registry Virtualization.

The concept of UAC (http://www.roth.net/blog/index.php/2007/04/02/vista-and-user-account-control-uac/)  is useful since it places finer control over what non-administrators can and cannot do. One of the core tenets of UAC is that a non-administrator should not be able to make changes that impact other users. For example if I make changes to an application’s settings they should only impact me, not other users of the computer. To accommodate this non-administrative access Vista virtualizes access by creating an alternate location for files and registry keys. The OS tries very hard to make this seamless so when an application tries to access a file or registry key it is redirected to the user’s virtual storage area.

In general this virtualization works, however for technical folk who want to access files directly they may be surprised to find the files are “missing”. Let say, for example, you want to manually edit an application’s configuration file. If the application was installed in the “Program Files” directory you may expect to find the file at C:\Program Files\MyApp\MyApp.cfg. But the file is really located in the path C:\Users\userID\AppData\Local\VirtualStore\Program Files\MyApp\MyApp.cfg.

Say what you will about Windows Vista but don’t think that it isn’t a big deal. Regardless of how you may feel about Microsoft, they put a lot of work into the Vista operating system. Sure the UI may not be as snazzy as Apple’s OS X and it is barren of some features from the promised land like WinFS. But there is an awful lot under the hood. Yes it is true that a Vista box really should have a recently upgraded machine to afford the resource costs the OS takes. But if you can afford the machine that runs the OS well rest assured that there are changes worth having. The problem that Microsoft faces is that these changes are not easy to quantify for the average consumer. How would you explain to your Mother about the benefits of the new media APIs? Or try convincing your boss to upgrade the entire IT department so that your machines could leverage PnP-X and Function Discovery. No, the innovations that underline the OS are not obvious to the layman. However there is one exception: security. 

For those not following Seattle news, we had the biggest wind storm since 1993–most argue it was stronger than that. Winds were clocked up to 90 MPH. Needless to say it knocked over trees and power line poles. Over 750,000 people were left in the dark for several days.


The Roth Consulting labs were offline 6 days. During this time the forum, blog, web, ftp and email services were down. We apologize for the inconvenience, but just like code, life has bugs.

A buddy of mine runs the Windows Incident Response blog over at http://windowsir.blogspot.com/. He is always digging up something interesting and pertinent to all your Win32 system administrators; regardless of whether you use Perl or not.


And if this stuff interests (or scares the Hell out of) you then you should have a look at his books, Windows Forensics and Incident Recovery (http://www.windows-ir.com/); it received a great review on Slashdot (http://books.slashdot.org/article.pl?sid=04/11/09/202220).

We are back after a 5 day outage. We apologize for any inconvenience that the outage may have caused, but this was an unplanned and unexpected outage. Apparently Verizon dropped an entire trunk of DSL connections on Friday (28 July 2006) morning. To rebuild the connections took 5 entire days. Rumor has it, however, no one was working on this over the weekend.


It is nice to know that Verizon’s utility monopoly is looking out for their customers.