Colin Cochrane

Colin Cochrane is a Software Developer based in Victoria, BC specializing in C#, PowerShell, Web Development and DevOps.

Moved and Upgraded

I just finished moving this blog into Azure and updating to the latest version of BlogEngine.NET.  Some of the images from older posts got lost in the migration, and I am working to restore them.

Searching Active Directory using PowerShell

I recently discovered a very convenient way to search Active Directory using the [adsisearcher] type accelerator. Here’s a simple example searching for a user based on their first and last names:

$searcher = [adsisearcher]""
$searcher.Filter = "(&(givenName=Pete)(sn=Peterson))"
$user = [adsi]($search.FindOne().Path)

Back in Business

My apologies for the downtime for the past couple of weeks.  My server decided to kick the bucket, and I have been incredibly busy since then, so I didn't get an opportunity to sort out new hosting until today.

On the plus side I have a lot to write about as I have been juggling a new sharepoint application, SQL 2008, and deploying a brand-spankin' new Active Directory infrastructure, among other things, so stay tuned!

Search Friendly Development On The Microsoft Stack Presentation

As promised, I have made my presentation from SMX Advanced available for download for those who are interested.  

Search Friendly Development On The Microsoft Stack (599.00 kb).

Thanks again to all those who attended, and special thanks to the organizers of SMX Advanced who put on a fantastic conference, and to Vanessa Fox for inviting me to come and speak.  Developer Day was a great success, and I can't wait to see what happens next year. 


The Broiled Laptop And My Lack of Recent Posts

Flaming Laptop

Note: This is not my real laptop.

I just wanted to give a quick update explaining the lack of posts here for the past couple of weeks.  Basically my trusty Compaq V3030CA laptop bit the dust about a week and a half ago, after a series of increasingly serious problems finally took their toll.  After a bit of research, I discovered that there were several lines of HP and Compaq laptops that had an issue with the default BIOS, and HP was offering a "Limited Warranty Service Enhancement" that essentially offers an extension of the manufacturers warranty if you:

A) Have laptop that is a member of one of the following HP/Compaq series of laptops:



  • dv20xx
  • dv21xx
  • dv22xx
  • dv23xx
  • dv24xx
  • dv60xx
  • dv61xx
  • dv62xx
  • dv63xx
  • dv64xx
  • dv90xx
  • dv92xx
  • dv93xx
  • dv94xx
  • v30xx
  • v31xx
  • v32xx
  • v33xx
  • v34xx
  • v60xx
  • v61xx
  • v62xx
  • v63xx
  • v64xx

B) Are experiencing wireless problems and/or display problems.

In my case, I had the pleasure of experiencing the wireless problems for some time (though I chalked it up to my router rather than my notebook) before I started getting random lockups and eventually extremely distorted video that would be immediately followed by my system locking up.


The Root Cause

 It turns out that the default BIOS for these particular laptops were configured to turn on the case fan when the processer (an AMD Turion x64 in my case) reached a temperature of 55° Celsius; a perfectly acceptable temperature for that chip.  Unfortunately the rest of the components in these laptops depended on that fan for cooling, and by the time the Turion chip reached 55° (which takes a while because the chip runs quite cool) the rest of the components in the machine were literally cooking themselves into premature failure.

So my machine is off at HP getting repaired free-of-charge, so if you are experiencing the same problems and have one of the laptops listed above, by all means contact HP and they will take care of everything (shipping, repairs) completely free of charge.   I'm expecting my machine back in about a week or so, at which time I'll get back to a more regular posting schedule. 


IIS 7 Site Won't Start After Upgrading to Vista Service Pack 1

After letting Service Pack 1 install overnight, I logged in to my machine this morning looking forward to exploring some of the new features added to IIS 7.0.  Unfortunately there was a small problem with one of the local web applications that I host from my machine.  Simply put, the application refused to start in IIS, and each attempt to start it resulted in a modal pop-up informing me that the process was in use.  I quick peek at the error log showed the following:




After I quick search I found a KB article over at Microsoft that addressed the problem.  As directed by the article, I popped open the command prompt and ran netstat -ano to get a list of what processes were listing for net traffic on what port.  First entry on the list identified the problem process.


(The screencap was taken after the problem was fixed, so the PID is not the same).  I opened up the task manager to find out what process was at fault, and it turned out that Skype was listening for incoming traffic on port 80 for some silly reason.  I closed up Skype and attempted to start the website and lo-and-behold, it worked.  I started Skype again, and everything was working like normal again.

I thought this may be of use to anyone who encounters a similar problem.

Internet Explorer 8 Beta 1: First Impressions

Since the IE development team releasing the first beta version of Internet Explorer 8 for developers last week, I've had the chance to play around with this latest incarnation of the Internet Explorer family.  While most of the focus has been on the improved support for web standards, which is immediately evident even in this early beta, there are many more new features and enhancements that are making IE8 look like its shaping up into a solid browser.

1) The Acid2 Test

First off, I'll confirm that yes, IE8 does pass the Acid2 test.


2) Loosely-Coupled IE (LSIE)

How many times have we all come across this classic?


Nothing was quite as annoying as having multiple tabs/browsers open and having an error on one page, or with a plugin, cause all of them to crash.  The IE development team has addressed this with a collection of internal architecture changes called Loosely-Coupled IE.  In a nutshell, what LSIE means is that the browser frame (everything other than the tabs) and the browser tabs are now located in separate processes, so if you visit a website that disagrees with one of your plugins, it doesn't result in IE completely crashing out.  Rather, you will see the classic "Internet Explorer has stopped working" window:


Which is now followed with the problem tab being recovered, rather than the entire browser:


3) Session Recovery

IE8 also offers a new session recovery option for those instances where you have an "unexpected" end to a session.


4) Domain Highlighting

A new feature of the address bar now highlights what IE considers the "owning domain" of the site you are currently viewing.  At first it may appear strange, and somewhat unnecessary, but when you consider situations where unscrupulous webmasters try using subdomains to fool the user into thinking they are at a site they are not (such as this feature becomes a subtle, but useful visual cue to quickly draw your attention to the true domain of the site you are browsing.


5) IE8 Developer Tools

A nice addition for web developers is the built in IE8 Developer Tools, which is the successor to the IE developer toolbar.  It features some nice upgrades from the developer toolbar, such as the ability to changes rendering modes on-the-fly.


A beefed up style-trace, which breaks down each style being applied to a selected element (showing you what specific element the definition is inherited from, and which stylesheet the definition is located in), and allows you to toggle the application of specific style definitions.



Unfortunately the developer tools are not as comprehensive as the phenomenal Firefox add-in Firebug, but are still a big step in the right direction, and provides the functionality needed to take most style-based issues with a web page.


The IE8 beta is quite stable, so I encourage you to give it a try and see what you think.  I'll be posting more impressions as I continue using the beta, but I'd love to hear some more opinions on it, so please feel free to share your experiences and impressions in the comments section.

.NET Code Tips: Converting A UNIX Timestamp To System.DateTime

After having to deal with UNIX timestamps in an application I am currently developing, I realized that there's probably a few people out there who are wondering how to convert a UNIX timestamp into a useable System.DateTime in a .NET application. 

Well the good news is that it's quite simple.  All a UNIX timestamp represents is the number of seconds since January 1st, 1970 12:00:00 AM.  So all we have to do is create a new System.DateTime structure, set it to 1/1/1970 12:00:00 AM, and use the AddSeconds() methods to tack on the timestamp.

Visual Basic:

   1: Function ConvertTimestamp(ByVal timestamp as Double) As DateTime
   2:     Return New DateTime(1970, 1, 1, 0, 0, 0).AddSeconds(timestamp)
   3: End Function


   1: static DateTime ConvertTimestamp(double timestamp)
   2: {
   3:   return new DateTime(1970, 1, 1, 0, 0, 0).AddSeconds(timestamp);
   4: }


Keep in mind that this method will return the time as Coordinated Univeral Time (UTC), so if you want to convert the value to local time you can simply modify the procedure as follows:

Visual Basic:

   1: Function ConvertTimestamp(ByVal timestamp as Double) As DateTime
   2:     Return New DateTime(1970, 1, 1, 0, 0, 0).AddSeconds(timestamp).ToLocalTime()
   3: End Function


   1: static DateTime ConvertTimestamp(double timestamp)
   2: {
   3:   return new DateTime(1970, 1, 1, 0, 0, 0).AddSeconds(timestamp).ToLocalTime();
   4: }

It's that easy to turn a UNIX timestamp into a .NET System.DateTime object. 

Happy coding!