Please join us at the Utah Fall Code Camp this coming Saturday, November 3rd, 2007.  This event is going to be excellent!  Come check out the site, register, browse the schedule and more.  Here's the official announcement:

Utah Fall Code Camp

Nov 3^rd 2007

Neumont University

Salt Lake City, UT

www.utcodecamp.com

 

The local Users Group Community is conducting a “Code Camp” for local software programmers at Neumont University. This Camp is Free to all.

 

We have a diverse topic range for this code camp. You can see the full list of sessions and speakers at www.utcodecamp.com We will be giving away at least one IPOD, software, Shirts, Books and Lunch and Breakfast will be provided. 

 

You will need to register on the site to be eligible for some giveaways so you need to go register now at www.utcodecamp.com if you haven’t already. If you registered on www.msutahevents.com you will need to re-register at the code camp site.

If you're developing ASP.NET applications on Windows Vista that are utilizing the Visual Studio-provided web server (a.k.a., Cassini) then you may have run into an issue where, when attempting to debug your website, Visual Studio immediately drops out of debugging once your application starts.  That is, you press F5, the browser pops up and displays the website and Visual Studio stops debugging and drops back into its standard development mode and the browser continues on running.  Your breakpoints are no longer active and you essentially can't utilize your development environment to troubleshoot issues with the site.

This has been happening to me of late.  I don't usually use the debugger in that sense to 'walk through' my code for a variety of reasons, but tonight I needed to.  Sure, I could attach to the process (WebDev.WebServer.exe), but that's a pain and I get tired of constantly attaching and detaching.

The culprit in my case was that http://localhost was in my Local Intranet zone in IE and, using IE 7 and Vista, I'm not authorized to debug intranet sites.  The solution is an easy one: move http://localhost to the Trusted Sites list in Internet Explorer.  Now the debugger attaches and remains attached, greatly simplifying the debugging process.

Thanks to everyone that came out to the Utah .NET User Group lunch today at Olive Garden.  We had a great turnout and a great time.  I think in the future we'll be holding the lunch around I-15 and I-215 as it's a major intersection and a great place to gather.  Any time we've attempted to hold the lunch elsewhere has resulted in just a small handful of people (3-4) whereas all of our lunches in the Fashion Place area have resulted in 10+ (today we had 14 if I recall).

Anyway, it was great to see everyone and we'll be doing it again in the future - maybe at the new Cheesecake Factory that opens next month...we'll keep everyone posted.

Later tonight (as it is now officially tomorrow being 3:26 AM) I have the opportunity to present on the topic of Design Patterns at the Utah County .NET User Group in Provo, UT.  This will largely be an adaptation of my Sept 2007 talk to the Utah .NET User Group, but I might throw in some new stuff.  I'm looking forward to it as I always am.  Come join us and see you there!

Time: 6:00 PM
Date: Oct 17th, 2007
Place: NuSkin building (1175 S 350 E, Provo)

Back when I was a trainer (years ago now), we had a little inside joke; it's pretty industry-wide in fact, but it was fun nonetheless.  You've heard of the ID10T (pronounced Eye-Dee-Ten-Tee), of course.  We had another known as the PBKACH (pronounced Peeb-Cache).  Essentially it stood for “Problem Between Keyboard and Chair”.  Well, today I experienced this first hand - literally.

Apparently, this particular server went down on Friday.  That is, no users could connect to it via VPN, all web services were down, the virtual servers were down.  No matter what the users tried a connection could not be established.  Any attempts to connect to or contact the server would fail.

Attempting to reboot the server remotely via the DRAC (Dell Remote Access Controller) interface would freeze at the following screen:

Any attempt to gain physical access to the server over the weekend was denied, but today when we got into the server room the problem was immediately obvious.  It wasn't a hardware failure as suspected and feared.  It was a literal PBKACH error.  In setting up the server rack, apparently the keyboard was placed on top of the server.  Additionally, a folding chair (poised on a small box) was also placed in the rack, precariously positioned above the keyboard:

Well, one thing led to another and the chair had slid off of the box and landed squarely on the ESC key of the keyboard, holding it down.  In and of itself this wasn't much of an issue except when the server rebooted (through an Automatic Update in Windows) the depressed ESC key was aborting the reboot and stalling it out.

No amount of remote access would have been able to remedy the issue - unless, of course, we were to install a 'rumble pack' in the server - I'll have to look into that one.

So after a good laugh, we chalked this one up as a good ol' traditional (and literal) “Problem Between Keyboard and Chair” and moved on.

I had the opportunity this past Friday (Oct 12th, 2007) to go to Seattle to represent Experlogix in the CRM 4.0 Partner Readiness Event.  We (Experlogix) and Scribe Software are the two sponsors that are participating in this event as it occurs across the United States over the next several weeks, so it's very exciting to be participating in this exclusive event.

As Experlogix is a sponsor of the event, I had the opportunity during the lunch break provide a 20 minute presentation on Experlogix and the web-based product Configurator.  I was very pleased with how smoothly everything went; it was great!  We got excellent feedback for the demonstration and a lot of interest.

It was a bit of a whirlwind trip for me as I flew in in the morning, talked to some MS partners, shared my demonstration/presentation, and flew out in the afternoon.  I have the opportunity again to represent Experlogix on Nov 1st in Denver for a similar event.  I'm really looking forward to it.

Boy, looking back at the past several months I really haven't done much in the way of keeping my blog up to date.  Perhaps I just needed a reprieve or perhaps it was too much Lord of the Rings Online.  It was probably a combination of the two.  Anyway, I have an update that I want to provide as it's plagued me in the past and been a point of repeated and renewed frustration.

I frequently create custom websites in development and uniquely identify them via a custom host header (entered into IIS either during site creation or after the fact).  Then I'd edit my hosts file to point that host header to my machine.  NOTE: If you use DNS and create a CNAME to the machine none of these problems exist.

When I attempt to open the website via IE 7.0 I am greeted with an authentication dialog box.  None of the credentials I enter will take, and after three tries I get a standard 401.1 (Unauthorized: Logon Failed) HTTP error page.  My first line of defense is to add the host header to IE's list of local intranet sites, but that doesn't have any effect - it still prompts me to log in.  None of my standard debugging techniques seem to yield any meaningful results.

As it turns out, Windows XP SP2 and Windows Server 2003 SP1 both include a loopback check security feature that is designed to help prevent reflection attacks on your computer.  This update causes authentication to fail if the FQDN or custom host header does not match the local computer name.

An article on Microsoft Support identifies this issue and how to work around it.  For my test cases, I tried the first method (”Disable the loopback check”) and that fixed it right off the bat.  Also note, that even though the instructions tell you to, I didn't need to reboot.  A simple IISRESET fixed the issue.

Essentially all I needed to do was edit the registry by creating the following DWORD value and assigning it a value of 1:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck = 1

I suppose that if I needed tighter control I might have opted for method 2 by specifying host names, but such wasn't the case.

I'm glad that got to the bottom of it.

I recently had the responsibility of moving an existing, in-use Microsoft CRM 3.0 database from it's current location/domain to an entirely new server on a different domain.  Not only was the target domain different but so was the licensing in that we were upgrading our product code and not using a Small Business Server license anymore.  Oh, and I should also mention that the organization name was also changing within the database.

This process is pretty painless, all-in-all, provided you're careful and pay attention to the goings-on of the process.

First of all, I backed-up the SQL Server databases (company_METABASE and company_MSCRM), archived them, and restored them into the new domain.  I also took the time to remove any schemas and logins from the databases that didn't apply in the new domain.

Then, I followed the instruction as provided by the Microsoft CRM Redeployment Tool (thankfully this existed to facilitate this process) on the CRM 3.0 disc 1 (also available via download here) to map users from the old system into the new domain.

When it came time to associate the new CRM installation with the original databases, however, I received the following error "The existing databases are not compatible with this installation of Microsoft CRM".  This was easily fixed by following the recommendations in a KB article and doing some spelunking on my own.  As it turns out, it wasn't liking the new databases because of an organization name change in CRM.  I also received an error because of the license key because we were moving off of the Small Business Server to another non-Small Business Server and the license keys could not be used together.

The following SQL commands fixed the issues:

UPDATE BuildVersion SET Revision = X (where X == the 3.0.5400.X of the SetupServer.exe product version)
UPDATE OrganizationBase SET Name = 'new organization name'
DELETE FROM License

After that, the installation was smooth as glass and without a hitch.

One thing of note as well once we were up and running.  CRM was operating correctly, but anytime we'd access the Reports section, we were greeted with the error "Report.config has invalid schema, and could not be loaded".  Likewise, when we'd go into the Calendar section we'd get an "Unexpected Error".

The fix for these were to make sure that the CRM 3.0 website and the SQL Reporting Services virtual directories were using the proper ASP.NET Version (1.1.4322).

Tonight we're switching up the .NET User Group meeting format somewhat, hopefully to the approval of all.  We're conducting what we're calling a “Presenter's Challenge”.  We're giving the opportunity to 4-5 presenters to take approximately 20-30 minutes each and present on various topics (we have LINQ, Mono, WPF, etcetra already scheduled).  Following the meeting we're giving everyone the chance to vote online for the best presentations.  The winners will be announced and awarded in September.

This should be a blast of an event and I hope it goes well - we'd like to have more variety in the meetings like this in the future.

Date: Thursday, August 9th, 2007
Time: 6:00 PM
Place: Digital Draw Network - Suite 300 (10897 South River Front Parkway, South Jordan, UT)

Don't miss it!