Codecs – You know I hate ‘em

Greg Tate — Tue, 13 Jul 2010 17:07:31 GMT

As I continue my quest to make lemonade out of the proverbial lemons tossed my way during the course of a day I leave you with the following tidbit on codec's.

Since web development really isn't my strong point this many may consider this common sense but for the administrator such as myself codec's are a pain, especially when they don’t play well with Microsoft (or vice versa) and you aren't particularly an expert on them.

The problem: Streaming Application wouldn't play sound on Windows 7 machine because of missing Sipro Lab Telecom ACELP.net codec.

MSFT Solution: A workaround (use a non MSFT multimedia playback program) See MSFT Official Solution

Since The MSFT solution wouldn't cut it for me so I was left a couple of lemons, I mean options, yes options.

Hack together some JavaScript to id the browser as IE8 or IE8 Compatibility mode(native to Windows 7), set a cookie, prompt the user to self install codec and redirect to the Streaming application.
Deploy the ACELP.net codec to all the users via MSFT tools (e.g SCCM, SMS)
Re-encode the audio stream with a different codec and figure out what XML file was referencing the original audio.

Obviously choice number one sounded best since it seemed kind of convoluted, insecure, and prone to failure. But that conclusion was only made after I wrote the darn thing and realized “Dude, the browser thinks your code is malicious”

Choice number two would have worked but then my counterparts who manager those systems were in the middle of upgrading them and wanted to focus on that before anything else (go figure).

That left me with Choice number three, so out came the MSFT Expression tool which promptly converted the original audio to a windows native codec. Change of file name in the XML config file on the streaming media and all is well.

Windows 2008 Server Logon Hang

Greg Tate — Tue, 20 Apr 2010 20:52:32 GMT

An interesting event occurred recently in a lab environment of a SharePoint Farm I was working on. This Farm (Moss 2007, Svr 2008, SQL 2008) was a medium farm scaled out in a virtual environment (VMWare)…If memory serves me we had some maintenance to perform on the VM Host which required us to shutdown all guests on this host. I figured this wasn’t a big deal since I had a fresh install of a functioning farm so I gave the VM admin the nod to take us down. Now we fast forward to the fun part…VM maintenance complete…Time to boot up the servers, up comes the SQL cluster, now the APP, then the Index, and last but not least the front ends.

As I “attempt” to log in I notice the WFE seems to be hung on the “Applying Computer Settings”…I’m not talking just a few minute hang, I’m talking an hour plus. After calling everyone in my rolodex (very short list) I had to call our pals at MSFT. Of course secretly I was hoping this was Kerberos issue since that meant I didn't have to solve it :-) (sorry Eric)

Anyway after days with MSFT their solution of course is to boot into safe mode and disable every service that isn’t already enabled in the normal startup via regedit…. I’m thinking “GREAT PLAN! Why did I call you again?"

As MSFT support was in their second day of diagnosis I noticed the following Microsoft KB article which mentioned certain essential services such as GP Client, DNS, Etc would not start automatically because of a deadlock between Service Control Manager and HTTP.SYS - This fit the observed behavior…Let’s try the fix in the KB…

Now for the fix

Boot Into SafeMode
Open Registry Editor
Navigate to HKLM\CurrentControlSet\Services\HTTP and create the following Multi-string value: DependOnService
Double click the new DependOnService value that you created
Enter CRYPTSVC in the Value Data field and click OK
Reboot Server in normal Mode

This event took three days from my life, days I can never regain so I offer this seemly simple fix yet buried solution in hopes I can save someone else.