You can do this today, like in 10 minutes...

OpenSearch is a format for describing how your site is searched, and optionally for adding Search elements to other formats like RSS. 

Auto-discovery of OpenSearch description documents is done via a link in your HTML head like so:

<link rel="search" type="application/opensearchdescription+xml" title="My Site" href="http://www.mysite.com/open-search.xml" />

The OpenSearch xml document is interpreted in the browser to add extra search providers in the integrated search function as so:

The contents of the file can be short or it can be long.  A bare bones example may be as simple as this:

<?xml version=”1.0” encoding=”UTF-8”?>
<OpenSearchDescription>
   <ShortName>My Site</ShortName>
   <Description>Search My Site</Description>
   <Url type="text/html" template="http://www.mysite.com/search.aspx?terms={searchTerms}"/>
</OpenSearchDescription>

The spec gives another simple, and one much more detailed example document.  The IE blog also goes into some detail... but in true internet fashion, View Source is the quickest path to an example

Security?

The bad news is, as of current browsers at time of writing (IE 7.0.6000.16473, Firefox 2.0.0.4) it seems controls are quite lax around what search template you can include, I had no problems setting the URL in the search template as being a completely different site!   

While it would be completely hilarious to posion someone's search bar as a prank with the following three facts...

• IE stores the search settings here: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes
• FireFox stores them in the filesystem: C:\Documents and Settings\<winprofile>\Application Data\Mozilla\Firefox\Profiles\<mozprofile>\searchplugins
• (sounds like google, not work safe)

I would ultimately like some control here.  I can't see anything in Group Policy for enforcing/allowing/denying new search providers.  I'd like to add one to all PCs for my internal Sharepoint site for example.

DasBlog

Tangentally, If you are looking for the file to edit to add a new link url to a dasBlog site it is:

\dasblogce\themes\*\homeTemplate.blogtemplate

Listening To:  Sonic Youth, Daydream Nation

OK, let me lay it out for you a la the Lost secret clues...

• Frank was interviewed on CSharpZealot.com. So was I.
• Frank is going to Play!  A Video Game Symphony tonight, as am I.

Thinkaboudit people, when have you seen us both in the same room?

The similaraties (*caugh* both of them) are really just too numerious to ignore!

Yes I have better things to do but no I could not help making more LolCats - this time no Tech.Ed

 

Linkage: ICanHasCheezburger & Teh Cats

I am going to be talking the Lolcat speek for the rest of the day and that is final.

This is the second post on Group Policy for web developers.  Part 1 was about managing the local Intranet Zone for your AD network.  This post will be based on a similar scenario.  Specifically, when issuing certificates from a local Certification Authority, like Microsoft Certificate Services that ships in Windows Server 2003.

Modern browsers give you a more pretty warning system than they did last year when you view a site that do not chain back to a Trusted Root CA.  This is still an important warning and we don't want to condition people into just clicking yes every time they see it.

The first thing you will need to do (and like the last post, a certain degree of domain administrative Godness is required...) is get the CA's certificate from the CA.  Using Microsoft Certificate Services, you want to choose the option highlighted below:

This will prompt you to save the certificate file.  Do this, then delete it when you are done. 

Next we need to install the certificate into our client machines.  We will need a GPO.  You may use the one from the previous example or make a new one. Again the place in your AD to create this will vary.  For smaller sites adding at the the top level is fine, but hands off the default policy.

Navigate to Security Settings -> PK policies ->Trusted Root CA's as in the screen below:

Right-click on the Trusted Root CA's container and choose Import.  Here, browse for the cert file saved in step one and you are done!

Finally, here is some linkage to much more detail about Certificates in AD.

OK, not a big cats person, but the lolcats meme has made it to Tech.Ed.

Frank Arrigo's post seems to be the epicenter, Brian has had a go too,  Plus more linkage here.

May I offer my contribution:

(And mad props to Frostdesign blog for the wholy unauthorized boosted image)

Seems that as a programmer, I'm a DHTB

What are you? 

Some sites that you may have on your internal network, such as Virtual Server console, Sharepoint, ASP.NET sites of your own creation, and so on, can require your AD credentials to log you on.  Typically the browser will prompt you for them unless you add the site to the Local Intranet zone. 

This quickly becomes cumbersome as the number of users grows.  Everyone will have to add the URL to their Local Intranet zone manually and that spells work.

Internet Explorer

All the IE Zones, including Local Intranet, can be administered by Group Policy.  Where in your AD you create your GPO will depend on the scale of your operation, for smaller sites a GPO at the domain level is not a bad choice.  I'd caution against editing your default domain policy, consider creating a new GPO just under it.

Edit the GPO and browse to the Site To Zone Assignment List, inside the Internet Control Panel \ Security Page settings:

  

The UI will let you add IP addresses, FQDN's or http/https addresses, and which zone they will belong to.

One nice side effect of this to watch for is the users can now not change their zones via the IE settings.

FireFox

For FireFox, you are going to have to create/maintain an all.js in the %installdir%\defaults\pref\ directory.

This is just a plain text file that can contain settings in the FireFox Javascript format.  For Integrated Authentication you will need to add the following line:

pref("network.negotiate-auth.trusted-uris", "comma seperated site list");

Listening To: Kruder and Dorfmeister, the K&D Sessions, part 1

c'mon, it's still the 5th in someone's timezone ;)

With a tip of the hat to the fine people at Make, I present you with...

A solar powered Prius.  Now that is environmental.  White paper here.  Shame it still looks like a Prius.

I was just surprised to work out that I have been on Windows Vista for about a year now nbsp; I joined the club with Beta 2 which was released in May '06   I also toyed with an earlier WinHEC Longhorn release but not in any substantial way.

From day one I’ve had UAC on.

Unfortunately one of the last guys to join the compatibility club was Visual Studio 2005 with the Vista Update patch

But just tonight I found the rare case of an MSI from Microsoft that failed with a cryptic message if not run as Admin: The Composite UI Application Block.

So I've put together a little grab bag of Vista UAC links and tips that I'm calling Strategies for life with UAC:

• First and foremost, know what has changed.  I wasn’t shocked when Buzz, which despite not having a substantial update since whoknowswhen, wouldn’t run out of the box.  The Audio subsystem had a major overhaul in Vista.  AppCompat came to the rescue here.
• Launch a cmd.exe shell as an admin, then run msiexec, regedit, or whatever from there.  This way you only have to elevate once at the start of your session.
• Use Compatibility, part I.  Choose XP SP2 from the Compatibility tab of the EXE File Properties page.  Raymond Chen referred to this as a Combo Meal of AppCompat settings.  Various degrees of slight of hand he said. 
• Use Compatibility, part II. You can also launch the Compatibility wizard from the Use an older program with this version of Windows link inside the Programs group in Control Panel.  This is the same set of options as is on the Properties page, however the UI is more suited to trial and error for troublesome programs, and you have the option to submit your results to Microsoft.
• Use Compatibility, part III. I am aware that there is an application compatibility toolkit available for ISV's, but haven’t had cause to look too much further.
• Use Virtualization.  Grab VPC 2007 (freebie)  I use VPC for application and installation testing with the Undo Disks feature, but it would be just as valid to run a VPC of XP or earlier if you had some app that would only run on a specific OS.

Just a note on Virtualization, I have not been able to find an authorative souce on the question of:  If I put Vista on my PC, is it legit to use my old OEM XP CAL in a VPC.  The rumours around the web seem to settle on:  a) depends on your license agreement, but I suspect it is an edge case and they are playing that card close to their chest.

If you can find an authoritive, public link on the above question please post a comment and there will be a prize.  You know I'm good for it people!

A couple of extra resources:

• Aaron Margosis' Blog
• The Non-Admin Wiki
• The UAC blog, not current but the archives have some gold.

Listening To:  Boards of Canada, Music has the right to children

There are not too many things I hate in the world.  Popcorn is one (no joke) another is the feeling you get when you discover something cool in the .NET Framework or Visual Studio and think: Damn!  Why didn't I find this sooner. I call it the Last one to the party Feeling.

Today, I'm talking about the SuppressMessageAttribute class (MSDN Link).

This attribute can decorate a class where you would like explicitly exclude a module matching a rule in FxCop due to a false positive.  Really it is no different to excluding the message in the FxCop project, but I think this is better because of how visible it is. 

When you exclude a message in the FxCop project it gets sucked into a black hole and you never see them again.  What if they are just a short term exclusion, like the old fav Microsoft.Design.AvoidNamespacesWithFewTypes - which may apply at the start of a project but not once it is off the ground.  Who is going to go and un-Exclude it from the FxCop project?

Also, this attribute takes named parameters, like Justification.  Again, FxCop lets you put a note in when excluding in the FxCop project but it gets lost to all but the most determined eyes.  Having the reason for the exclusion right there in the code means it has a better chance of getting on-going attention as it may not always be as valid as it is today through circumstance or refactoring.

This attribute requires you to define a symbol - CODE_ANALYSIS.  In NAnt you can add define = "CODE_ANALYSIS" on your CSC or VBC Task and/or define the symbol in your Project properties, depending on how you build:

I've just got a couple of lessons from the last week to share around developing Office 2003 (and specifically Visio 2003) Add-Ins

I'm also trying to saturate this post with links because I have come up with a good size folder in my bookmarks for what started out to be a simple task.

• Grab the PIA's.  Anyone who wants to run the Add-In will need them.  Alternatively they can be installed from the Office Add/Remove/Repair under the guise of .NET Programmability Support, but in reality the user may not have the media or security access to do this.  Do NOT however ship the PIA's in your bits.  Ship the PIA's with your bits:  This means 2x MSI's.
• Using NAant to automate the build with csc.exe & vbc.exe is suboptimal.  I'm keeping my project to one small assembly that depends on the PIAs, and also depends on another assembly that does the heavy lifting but has no ref to the PIA's.
• Strong Name everything.  Well, strong name everything anyway, but when trying to pass of managed code as COM it is essential.
• You cannot load a .NET DLL, even one with the ComVisibleAttribute on the Assembly or Classes, via the Office UI.  You just can't.  KB316723 gives an explanation.  This is because Office will try and register it the old regsvr32 way, which of course won't work.  To get a .NET DLL into the Macros -> Add-Ins list, you must write the registry entry under: HKEY_CURRENT_USER\Software\Microsoft\<office program name>\Addins\
• This brings me to my next point.  KB316723 hints at it, but your setup must write a HKCU key not a HKLM key.  The Shared Add-In Wizard in Studio is ambiguous when it shows you this choice:

• I know this may be contentious, but consider using VB.NET over C#.  This depends of course, but some parts of the Office object model make heavy use of Optional Parameters which C# does not support.  It has been noted elsewhere what Type.Missing can do for readability.  Having said that, it does vary greatly depending on where in the Office Object Model you are.
• Spend some time with the Setup project that the Shared Add-In Wizard makes and test it.  Once you like it, reverse engineer it to a WiX script and feed that to your automated build.  For the record, you do that with:

Dark.exe –x path Debug/msi My.wxs
Candle My.wxs
Light My.Wixobj

• To extra points when dealing with WiX-ified MSI's
  1. It's useful to note that the extracted (-x) resources take many forms.  DefBannerBitmap.ibd for example is just a bitmap.  I think it is easier to rename it to .bmp & tweak it in Photoshop than to add a new banner in Visual Studio.
  2. The Add-in reg setting mentioned in point #4 above references an assembly version.  Visual Studio tweeks this for you but your WiX script will be frozen at the time your Dark.exe'd it.  So don't auto-increment your assembly version numbers, or tweak you WiX script.  The choice is yours but your MSI must write the version of the Add-In DLL to the target machine's registry.

Listening To: Leftfield, Leftism