Invalid URI scheme 'file://' for map control. Control must be hosted in a HTTP(s) website.

But... I'm not using file:// for my map control.

So, I'm programming with ESRI's Silverlight Map control. This started out as a test project, but it's become more of a production application. Instead of moving all my code to a new project, I'll just rename it from SilverlightApplication1 to MyProdcutionApplication.

I rename all the namespaces, remembering to rename the corresponding XAML references that don't get refactored. Then I rename the projects themselves and have to organize the folders.

So, I remove all the projects from the solution, rename the folders, and add them back in. I hit compile and woohoo, no errors. So, I go to run it and I get the following gem:

I recheck my map references and sure enough, I <am> using http://path/to/my/rest/endpoint ... so.. off to google.

After a 20 minute search trying all variations of the error, I finally stumble upon this thread in the ESRI forums. Back in 2009, Don Freeman got the same error and lo and behold, it was because the default start project was the Silverlight Application, not the Test Website.

I flipped my startup project to the test web app and poof... all is well

Logon Failed in SSMS on Windows 2008 (or Windows 7)

We recently moved our SQL Server from Windows Server 2003 to Windows Server 2008. When I tried to connect through SSMS on the server I got a rather odd error:
.

Now, I'm a SQL Administrator and am able to connect to the server from my local PC (Windows XP). I check the SQL Event log and see the following:
. After some Googling I find an article referencing UAC. It suggests right clicking on SSMS and running as administrator. I do this, accept the annoying message, and yowza, the system works.

Now, this is all well and good, but I really don't want to have to right click and run as administrator each time. Plus, as infrequently as I actually log on to the server to use SSMS, I'm sure I'll forget and end up googling this exact same error again. So, I poked around a little bit and found out that you can force the .exe to always run as administrator

• SSMS Properties
  
• Compatability Tab
  
• Show Settings for all users
  
  Notice how this is now for the ssms.exe file, not for the shortcut anymore
• Check "Run this program as administrator"
  

Now, whenever you run SSMS on the server, you will get the annoying message and it will work. I'm a little surprised that Microsoft didn't include that in the install package for SQL Server 2008, but at least there's a pretty easy fix.

HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials

I get a call this morning that one of my applications isn't working. I go to check it and sure enough I'm getting the following: "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials". This application impersonates a specific Windows account so I check the usual stuff...

• Password change : Nope
• Security on the filesystem: All set properly
• Long username problem : Nope, not the problem here
• Account Disabled: nope

So, I'm running out of ideas.. so, I try to recycle the App pool (smart me, created a separate application pool just for this particular application). The pool comes back online and still no go.

I start looking through the log files and I'm not getting any more information except for the "invalid credentials". I take a look at the account again and chuck it into domain admins just to get this up and running. Recycle IIS this time and poof... same error

So, I've now ruled out any possible unauthorized access issue. So I take one final look th the user properties and I notice that even though the account isn't locked out, the password has lo and behold expired. Then I notice that the checkbox for "Password never expires" is not checked. I check the checkbox, apply the changes, and poof.. everything works

So, the lesson here, boys and girls, is to make sure you make sure your service accounts passwords do not expire

Sending Mail in SQL 2000

When our fleet division gets a new vehicle, they spend a few days (or weeks) prepping it and getting it ready. They assign the vehicle number, hourly rate, and a bunch of other stuff. After they're done, our finance department needs to track this in their inventory. The current fleet maintenance software can generate a report, but it doesn't contain everything that finance needs, so, the current practice is:

• Enter the data into the fleet software
• Re-enter it into an old access database (which has a report that has all the info)
• Print off the report from Access
• Make 3 copies
• Interoffice them to Finance.

I've been tasked with coming up with a better solution. After a few minutes of deliberation, a trigger seemed like a logical solution. The trigger will just fire off an email to all the parties when a vehicle is added. No problemo.

Sending mail in SQL Server is nice and easy. Just use sp_send_dbmail and you're good to go. That is, along as you are using SQL 2005 or better. Back in the dark ages (SQL 2000 and 7.0), however, you didn't have sp_send_dbmail. Instead, you had xp_sendmail.

Now, you ask, what is the problem with xp_sendmail. A bunch, but here's the highlights :

1. It's deprecated. I'm surprised it's still around in 2k8, but I bet it won’t be in the next version
2. You need to run it as a db_owner or a sysadmin. Now, you can grant others permissions to it, but that means mucking with permissions in the master database and that's generally frowned upon.
3. You can only send mail as the profile that's set up. This may not seem like a big deal, but I send out emails from the database and I want the recipients to be able to respond to different people based on the message. That means I'll have to set up a separate mail profile for each respondent.

Of course, the SQL Server development team saw these problems (and probably oodles more) and came up with sp_send_dbmail which addresses all of these

Now, since I’m using SQL 2000, I don’t have that option. After much googling, I was able to find xp_smtp_sendmail. The only issue was that most of the links were broken. So, I had to do a little more sleuthing and eventually found the right page in SQLDev.Net. After following their step by step instructions, I was able to send mail as the appropriate person and cut down about 10-15 hours of redundant work from the process.

Yay me.

Of course, we won’t mention that I forgot that the deleted table in a trigger is aptly named deleted and not updated. D’Oh

IIS Username too long causes 401.1 error

So, I'm making a new ASP.Net webpage that is accessing a database through Integrated Security and it's testing fine on my local PC running under my user credentials. All is working fine and dandy.

I go to publish it to my live server and remember that I have to set the security of the directory to be other than the IUSR account in order to access my database. No problemo. I just fire up IIS and hop over to the directory tab.

I hop back over to my browser and I get this lovely message:

HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.

I recheck my username and password and sure enough they are valid. I check the directory permissions and they're set properly as well. Then I remember.. the ASP.Net temporary file location (c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files) and sure enough that's set right too. So I check the IIS log file and it's as helpful as the error message.

So. Off to Google. First article mentions separating the Application Pool for separate user accounts. Seems unlikely, but I give it a whirl. Create a new App Pool. Set the Security, recycle IIS jsut for good measure and ... still the same error message.

It's getting to be quitting time.. so ... off to sleep on it.

I get back to work and check other ASP.Net apps that use security and they're all set in the Default App Pool (Which I really need to separate when I have some free time) and the security is set how I'd expect it.

I then notice something peculiar about the account that i'm using. It's a wee bit long. See, we used to use a common domain account for all our ASP.Net apps (ASPNet) but someone typed it in wrong once and it got disabled and all my apps failed. So, a year or so ago, I started creating new accounts for each ASP.Net application (ASPNetCalendar, ASPNetAgenda ... ). This account was named ASPNetContractorServiceRequest. Now, when I was creating the account I got some goofy error message about the name being too long, but I just ignored it figuring it was some old legacy error message. Turns out that the error message WAS important. When I created the account it actually truncated the name so 20 characters (ASPNetContractorServ) So, I changed the username and poof everything worked.