Kerpau!

Windows Media Player handles sound differently when the session is connected via Remote Desktop. If you are connected using RDP/RDC, exit the session and reconnect using “mstsc /console” and then try playing the file again. Assuming that everything else is running properly this will work for you. Here are the rest of the details on the error message:

C00D11BA: Cannot play the file
Windows Media Player cannot play the file because there is a problem with your sound device, such as a sound card or sound controller. You might encounter this error message for one of the following reasons:
Your sound device is in use by another program. Quit other programs that might be using your sound device, and then try to play the file again.
Your sound device requires an updated driver. To determine if an updated driver is available, see the Windows Update Web page at the Microsoft Web site, or see the sound device manufacturer’s Web site.
The selected sound device does not support Secure Audio Path (SAP). If you have multiple sound devices installed on your computer, try using a different one.
Your sound device is not functioning properly. To troubleshoot the problem, see the Sound Troubleshooter in Windows Help or refer to your sound device’s documentation.
You do not have a sound device installed on your computer. Install a sound device, and then try to play the file again.
To use a different sound device
On the Tools menu, click Options, and then click the Devices tab.
Double-click Speakers, and in Audio device to use, click a different device.
Error ID = 0xC00D11BA, Condition ID = 0×00000000

I’ve had the opportunity to work with a lot of sysadmins of varying experience levels lately and think I have it all figured out. Inexperienced sysadmins expect things to work. Experienced sysadmins expect things to not work. This fundamental mindset leads to vastly different behavior patterns among the two types. If a sysadmin expects a system to fail, s/he will be more likely to perform regular backups, design redundancy into solutions, read the manuals before deployment, test a solution before deployment, test a solution after deployment and so forth. The inexperienced sysadmin reads the marketing materials, believes every word that comes out of the salesperson’s mouth, doesn’t plan for failure.

So when the system ultimately fails, the experienced sysadmin has an entire array of options to choose from. Like backups, failovers and expertise gained from reading the manuals. The inexperienced sysadmin has to resort to trial and error fixes on a live system with no fundamental understanding of the technology. This usually make the issue worse and leaves them in their last resort scenario - bugging tech support. Not good if your job depends on it.

Oddly enough, I found this piece of advice on The Simple Dollar post on Wealth.

Err on the Side of Simplicity Where Possible

It was mentioned in the context of money but is definitely applicable to system design. It’s really a variant of Occam’s razor and one I’ve used many times when considering options in design, deployment and maintenance of complex systems.

All things being equal, the simplest solution tends to be the best one

Although, I have no idea why this happens, here is how to fix RDP/RDC connections after a SQL Server 2005 installation breaks it.

• Control Panel > Administrative Tools > Terminal Services Configuration > Connections
• Delete the RDP connection
• Right-click Connections and select Create New Connection
• Accept the wizard’s defaults
• Name it RDP-tcp or something descriptive
• Reboot, and you’re back in business!

Unfortunately, the reboot is necessary.

Sorry but it won’t work. I can’t imagine why Microsoft would have dsquery and dsget operate on only a partial set of the user’s properties and leave out others but they did provide TSPROF to bridge this particular gap.

tsprof

TSPROF /UPDATE [/DOMAIN:domainname|/LOCAL] /PROFILE: username
TSPROF /COPY [/DOMAIN:domainname|/LOCAL] [/PROFILE: ] src_usr dest_usr
TSPROF /Q [/DOMAIN:domainname|/LOCAL] username

A simple dsquery command piped to dsget will show us the home directory for all users in an Active Directory domain.

dsquery user -limit 1000 | dsget user -hmdir

To change the home directory setting, use a variation on the same command.

dsquery user -limit 1000 | dsmod user -hmdir \\server\share\$username$

The $username$ variable will be populated with the value of the current user’s account name.

I have been seeing requests for notified-Compliance_page, a non-existent page in my Web logs lately. They are coming mostly from Google networks with Mediapartners-Google/2.1 as the user agent. Does anyone know what these are about? If so, drop me a line or leave a comment. There isn’t much information on the Web about this and I would love to know more. Thanks!

This DSQUERY lists all e-mail addresses in Exchange, and Active Directory including Public Folders, Contacts and User mailboxes.

dsquery * forestroot -scope subtree -filter “(&(mail=*)(proxyaddresses=smtp:*))” -attr proxyaddresses - limit 10000

The output is a bit messy but nothing a little bit on time in vim can’t fix. Bharat Suneja has a very elegant script that does the same thing but it doesn’t include the SMTP addresses of public folders.

I was pretty geeked out about this - Are Sysadmins Really that Bad?. I submitted it about two months ago. It’s the only article I’ve ever submitted and it got accepted! Smakynet suggested I write about it because it gives me “street cred” as a geek.

The actual name of this is Intel(R) Processor Identification Utility and can be found by searching at http://downloadfinder.intel.com. However, I have to poke around Intel’s site for a few minutes every time I want to download the utility. For convenience, here is the URL - http://www.intel.com/support/processors/tools/piu/