When copying MDF/LDF files from a SQL 2000 installation to a SQL 2005 installation, diagrams will not open and the solution to getting them to open properly is non-intuitive.

Here is T-SQL Code to fix the problem.  This is run on the SQL 2005 Server after the MDF has been attached in SQL Management Studio.  Substitute your database name where is says "Nexus":

I installed WSUS at work and have been learning how to administrate/manage the service.  Here's a few tips:

* You've got to configure Group Policy after installation in order to get clients of the domain to start using WSUS instead of Microsoft Update.  There's ample info on the 'net about how to configure GP.

* Once you've got Group Policy updated and replicated, you can force a client to update by typing GPUPDATE at the command line.

* To force a client computer to contact WSUS to update itself, type:

      wuauclt.exe /detectnow

* To keep WSUS fit and trim so that it runs well, copy/paste the following to a batch file on the WSUS Server and set it up as a Scheduled Task.  This is a script that someone else wrote that I found doing some Internet searches in trying to improve WSUS performance.  If you don't run this batch file on your WSUS instance, Approving Updates through the WSUSAdmin interface can become painfully slow.

Please note, you will need to download WSUSDEBUGTOOL.EXE -- which is called "Server Diagnostic Tool" and available here: http://www.microsoft.com/windowsserversystem/updateservices/downloads/default.mspx.  After download, run and extract the wsusdebugtool.exe file to the X:\Program Files\Update Services\Tools directory on the WSUS Server.  Make sure to configure the first TWO lines of the batch file so that the paths are correct.

I've had a serious love/hate relationship with MS Exchange since version 5.5.  On the one hand, Exchange provides a rich user experience.  On the other hand, it is a beast of a product to manage/administrate.  Perhaps one of the most harrowing aspects of Exchange is proper maintenence and disaster recovery when failure does occur.  And yes, failure WILL occur.  I guarantee it.

With several of my jobs over the past 10 years, including my current one, I have had to act as the Exchange Administrator (lucky me).  Here are some of pearls of wisdom that I've collected throughout my career.  Most of this stuff I learned from a very talented Exchange Guru from a small outfit in Cincinnati called KeyEdge (http://www.keyedge.com).

* It is essential to backup the Exchange Server using NT Backup on a regular basis - as in every day.  If you look into the C:\Program Files\ExchSvr\MDBDATA directory (substitute your drive letter and proper path as necessary), you will likely see many .log files that are about 5mb in size each.  These files contain critical information about your mail and if they are lost, you will lose mail.  Run NT Backup on the Exchange Server, expand the Exchange Server folder and click the Microsoft Information Store.  I find it makes the most sense to back this up to a file on the local server or over the network.  Ideally, you should then pick this file up in your nightly backup routine to move the file to tape or elsewhere.  Once the backup completes, all the .log files magically disappear, because they get committed to the Exchange .EDB file(s).

* About every two months, it is important to defrag the Exchange Server databases (Priv1.EDB and Pub1.EDB (if you have public folders)).  These Exchange databases are similar to SQL Server in that they grows incrementally as storage requirements increase.  Even though you might instruct all your users to do a deep cleaning of their mail on the server, you will notice that the size of the .EDB files do not decrease.  This is because Exchange has already allocated that amount of disk space for its storage requirements.  To shrink the EDB files you must defrag.  After defrag you will notice that the EDB files have contracted to the actual current storage requirement.  Defragging requires taking the information stores offline and then running ESEUTIL from a command line.  See this article: http://support.microsoft.com/?kbid=192185.

* Make sure you know your Legacy DN.  This will be important if you ever need to restore your Exchange Server.  See http://www.microsoft.com/downloads/details.aspx?FamilyID=5EF7786B-A699-4AAD-B104-BF9DE3F473E5&displaylang=en to get the utility.  Just run it and write down the LegacyDN information and keep it safe in the event of a disaster.

* This site contains documentation on a SWING migration.  http://www.sbsmigration.com/migration-projects.php.  Although it says "migration" there is highly detailed information on restoring an Exchange Server in the event of a catastrophe.  Its unorthodox, but it works completely and absolutely.  Don't be fooled by the Small Business Server crap.  This stuff is the real deal.

* In the event of Send/Receive errors reported from Outlook, a likely culprit is the Offline Address Book, which Outlook caches.  This can cause all kinds of strange things to occur, such as "Exchange Server Reported Error (0x8004010F).  The thing to do here is go into the System Manager for Exchange and Rebuild the Offline Address List (Recipients, Offline Address Lists, Default, Offline Address List - right click and choose Rebuild).

* To setup the Exchange System Tools on a workstation so you don't always have to remote desktop to the Exchange Server to use the improved Active Directory for Users & Computers tool and/or to manage the Exchange Server, you can install the System Tools on a Windows XP workstation.  Pop the CD in (or mount the ISO with Daemon Tools or similar) and start by acting like you are going to install Exchange on your XP box.  On the 2nd screen, choose Install System Tools only, then on next screen (or one after that I can't remember), choose CUSTOM install type and then set INSTALL next to System Tools.  That's it.  Make sure you have installed the pre-requisite items that the installer indicates are required prior to getting to this step.  For XP, I believe this is IIS and SP2.

* Make sure to install the latest Exchange 2003 Service Pack on the Exchange Server.  Duh.  Check for security updates after that.  Duh.  (http://update.microsoft.com).

* You can find most answers you need by using Google.

Over the past year+, I've noted an incredible increase in form spam through the various web sites that I've authored and continue to manage.  As a result, I've had to go back and add CAPTCHA controls to the forms in some cases.

I'm working on a new .NET project called ArtOverture and needed to dig into a .NET based CAPTCHA control.  Looking around at the source code for dasBlog, I learned about Jeff Atkins CaptchaControl.  It's written in VB.NET for Visual Studio 2003 and ASP.NET 1.1.  However, I found that you can include the compiled DLL just fine as a toolbox control in Visual Studio 2005.  The control works perfectly without any need for recompiling.

Here's the link to Jeff's Code Project writeup on CaptchaControl.  Full source code is available.

 http://www.codeproject.com/aspnet/CaptchaControl.asp

I've been toying around with the idea of setting up my own blog for sometime.

After doing a brief Google search on ASP.NET based blog tools, I found David Hayden's note where he recommended DasBlog.  Took me all of 15 minutes to get up and running on my box.  So far so good.