Use Windows Authentication for SSMS as Domain User from Non-Domain Account

For those that work with Active Directory environments, but (for whatever reason) prefer to keep their computer off the domain (consultants — that’s probably you!), you DO have the option to run SQL Server Management Studio using Windows Authentication from your non-domain user account. I only recently discovered this, and I can’t believe it took me this long to find it.

SQL Server Management Studio 2008:
runas.exe /netonly /user:MYDOMAIN\myuser "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"

SQL Server Management Studio 2005 Express:
runas.exe /netonly /user:MYDOMAIN\myuser "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe"

You get the idea 🙂

Now when you run Management Studio, you can select ‘Windows Authentication’ to login to your target SQL Server using your domain credentials. No need to use RDP to remote to your SQL Server or running it in a Domain-enabled Virtual Machine!

Exclude Squid Cache from updatedb.mlocat

One of the Squid servers in a cluster I manage had an unusually high load, while the rest of the Squid servers with a relatively equal amount of connections were within acceptable load levels.

While reviewing the process list, I found that updatedb.mlocat was running during the busiest time of the day. Turns out it is enabled by default in cron.daily on Debian Lenny, and it was using a noticeable amount of CPU resources. Wtf?

It was attempting to index all the files added to the Squid repository. On these servers, I have a separate partition for Squid in /mnt/squid/, and so UpdateDB can’t tell if it’s supposed to keep track of all these files alongside everything else in the system. Luckily, there is an easy solution.

Exclude your Squid cache location via the “PRUNEPATHS” variable in /etc/updatedb.conf (in my case it was /mnt/squid)

I added my Squid Cache location to PRUNEPATHS, then the process dropped off the radar, and server load returned to acceptable levels.