My personal opinion is Microsoft shouldn’t have been forced to release this. If you FORCE a choice for a web browser, you should also force a choice for every single application that comes with Windows.

Additionally, I fail to see why people should be forced to pick from a number of free products. Perhaps a better option would be for Microsoft to allow third parties to produce branded versions of Windows and then users can make their initial choices at the point of purchase.

This, of course, assumes a level of knowledge of the end users so questions like “where have all my favourites gone?” don’t happen…

Anyway, this was supposed to be a vaguely technical post and not a rant.

So, as a systems administrator, how do you block this update?

If you are using an internal update server such as WSUS or SCCM (which I love), then you have the simple option of not approving the update for release.

Otherwise, Microsoft have released a KB article showing a simple registry key that can be set to prevent the Browser Choice screen running – KB2019411.

So, as a sysadmin, how do you implement this?

Well, you can custom roll a Group Policy to set this as a preference on your client machines. I’ve written some GPOs before, but in this case I’ll simply direct you to this blog post by Christoffer Steding where you can download his version.

However, in my opinion, a much more graceful group policy to set is a software restriction policy. This has been documented by The Angry Technician.

This weeks challenges related to SQL 2008 and Office Communications Server 2007 R2.

My SQL 2008 issue related to a “feature” known as Parameter Sniffing. In simple terms, SQL Server generates a execution plan based on the parameters passed to a stored procedure the first time it’s executed. Of course, given that the parameters passed may or may not be typically representative any given execution the “optimization” may be way off. A good indicator this is an issue is if you execute that SQL code in Query Analyzer and the time taken is significantly shorter than the same query run through an “optimized” stored procedure.

There is a really good overview of this on sqlpointers.com. The workaround is fairly simple if a little annoying.

My other big issue I lost a fair amount of time to was with OCS 2007 R2.

Packet sniffing (using Wireshark or Microsoft Network Monitor) between my server running the Mediation Server role and my IP PBX (Cisco CallManager, but thats irrelevant) showed that the SIP FROM address being used to establish an outbound call was username@domain.com and not using an e.164 number eg +1234567890@domain.com. This meant that the PBX was unable to establish an appropriate Caller ID to use when establishing the outbound call via the carrier.

After many hours of trailing top to bottom through all the config options for OCS, and seriously considering a fresh build of the core server, I found the issue was related to a setting being force in Group Policy from a previous OCS project.

This setting was forcing the OCS client to operate in the remote call control mode, which was overriding the setting on the OCS server that meant users were operating in Enterprise Voice mode. The setting in question is TelephonyMode and it was set to 2.

One nice little (undocumented!!) feature that came to light while troubleshooting this issue is the ability to get a summary of the operating OCS client configuration! Simply hold down the CTRL key and right click on the OCS icon in the system tray. Select the “Configuration settings” option and a nice little window will appear with a list of the settings in operation!

This helped me diagnose the issue as it showed the address my client was using for its Line setting was the setting it should have been using when I was previously using Remote Call Control of my Cisco handset and not my full e.164 number as I would have expected.

Always nice to finish a Friday on a positive note

Theres a big hoo-ha going round at the minute about a number of viruses that are exploiting autorun.inf to spread.

You can read all the gorey details over at CERT “Microsoft Windows Does Not Disable AutoRun Properly”

Essentially, the recommended fix is to set a registry key. I did read somewhere that this makes windows handle the file as a Win95 ini file but sadly I can’t find the blog/article where I read that anymore.

Approaching this as a sysadmin and wanting to undertake minimal effort to resolve this issue I’ve create a Group Policy adm file to solve apply it to all the machines in an Active Directory domain. I’ve copied the contents below and attached the file to this post.

To use it:

1. Create a new group policy object in your AD
2. Edit it, right click on the Administrative Templates folder and remove all the default ones listed and add the one below.
3. Right click on the Administrative Templates folder and change the view filtering to not hide settings that can’t be fully managed
4. Group poicy editor will now display the setting to disable autorun which will set the appropriate registry key

ADM files are just text. You can either download the one below or copy and paste this (watch for the line wrap on the last line!):