travis' brain dump

Now, when I say “pesky annoyance” I mean down right frustrating. Say your thumbnails won’t work on your xbox 360 when viewing items thrown out over media sharing and you’ve got this wonderful errors blasting around your event log:

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Event ID:      10016
Description:
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}
 to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Now, just think about how tech-savvy you really are. You know what’s up. You’re going to go find out what application this is by finding the AppID in the registry then head over to Component Services and go fix this up, right? You start “dcomcnfg” and you browse over to “Thumbnail Cache Out of Proc Server” and try to modify it… no love. Greyed out options and all you’ve just been denied by your trusty operating system. You know you’re and administrator but behold, you’ve been given the finger by Windows.

No worries.

Someone, somewhere decided that they would make a security consideration here and grant only “Trustedinstaller” full control permission instead of Administrators. How dare they huh? To fix this up, do the following:

    1. Open Registry Editor and browse over to ‘HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\AppID\{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}’
    2. Right click on the {AB8902B4-09CA-4BB6-B78D-A8F59079A8D5} key and choose “Permissions…”
    3. Just as you would a file, take ownership and assign it to ‘Administrators’ then go back and grant ‘Administrators’ the ‘full control’ permission.
    4. Restart dcomcnfg and modify away.

Once you’ve made your modifications and granted Local Activation permissions to NETWORK SERVICE, you should eliminate those errors.

This trick can be applied to ANY CLISD you can’t modify in Component Services DCOM Configuration. 🙂

Ok, so since my post a couple days ago I’ve been doing a lot of research and such.

The big kicker that got me on this whole thing was the the installation worked fine on my x32 VISTA but not on my x64 VISTA installation inside the same domain but yet replicated the same behavior on my x64 Windows 7 system as well. I think it led me down a winding road in the opposite direction to be honest.

So, today I decided I would give this another shot. I needed to figure this out. I don’t do well with problems that I haven’t resolved and usually need to find some way to fix them. So, in doing so, I loaded up x64 in a virtual setup and decided to go to town on it. This time I didn’t install it to the domain but left it in a workgroup. Lo and behold, the 360 went right in. The irritating thing here was that since it worked on my 32bit but not on my 64bit while being in the same domain, subject to the same GPO I dismissed GPO as being the culprit (as you can read in my previous post). This was premature of me and now I’m kicking myself.

So, now that I’ve officially ruled out that it was an issue with x64, what’s the next step to make sure I can get this to work in my normal installation. Here’s what I did:

1) Uninstalled the MCE from Windows MC and Uninstalled software from the XBOX 360. (Xbox Article on Removal)
2) Made sure the user MCX1 was deleted and that I cleared out the certificiates. (Microsoft Article on Removal)
3) Disjoined my Windows box from the domain and rebooted.
4) Created a new Computer OU in my AD tree and made sure to block inheritance on group policy objects as well as ensure there were no links to the default domain policy in place. This makes sure that no GPO properties are applied to the computers located in this container.
5) Logged in with a local Administrator account on the Windows box and rejoined it to the domain. (don’t reboot)
6) Once the computer was registered it now shows up in AD in the “Computers” OU. If you had it in a custom OU prior to this, check that OU since AD is pretty smart and will sometimes put things back where they were. Move the computer to the blocked OU and now reboot it.
7) Upon reboot, login as the local administrator and run your MCE setup again. It should work fine this time.
8) Logout and log back in as your regular user. Your account profile settings should be just fine. Since your SID never changed from the domain, it will match you right back up where you need to be and your preferences and such should still be fine. If you’re paranoid about this, feel free to back up your profile prior to playing with this.

Currently, I’m logged in as my normal user account and everything seems to be fine. I had to go back in and clean up some of my media sharing directories that I was watching and repoint the MCE to the right media folders to watch but that was it. Everything is working great now.

My only guess is that perhaps when I deployed a 2008 server out into the dc structure and extended the schema it added something out there that my 32bit machine didn’t pick up on. I don’t know. If I get bored one day, maybe I will pick this apart and find out the exact GPO settings that are causing this issue. Until then, this is a perfectly acceptable way to resolve this in a home environment.

If you have any questions, let me know. I’ll fill in the blanks if there is anything that is unclear.