If you downloaded MSCRM and you do the server install you are likely presented with a lovely missing requirements screen like the one below, which you then need to download the requirements and install. Besides the waste of time and bandwidth, there are occasions where this isn't possible so this is how you can download the files yourself (using your favorite download manager for added speed) and put them in the install location so the installer finds them. It also helps with the fact that no matter if the Visual C++ runtime is installed it wants to download and install it each time.

Note: This is compiled from a x86 install. The x64 install mileage may vary.
The file locations are relative to the setupserver.exe.

• Microsoft .NET Framework
• Download From: http://go.microsoft.com/fwlink/?LinkId=91338&clcid=1033
• Location: DOTNETFX\dotnetfx3.exe
•  Microsoft Visual C++ Runtime
• Download From: http://go.microsoft.com/fwlink/?LinkId=91355&clcid=1033
• Location: VcRedist\vcredist_x86.exe
•  SQL Reporting Service Report Viewer Control
• Download From: http://go.microsoft.com/fwlink/?LinkId=91351&clcid=1033
• Location: ReportViewer\ReportViewer.exe  

Note you find this information in the crm40srvsetup.log file in <system drive>:\Documents and Settings\<username>\Application Data\Microsoft\MSCRM\Logs

This is a great proof of how NOT to protect software. When you try to uninstall it can ask for a password configured by the network admin, but what it the server admin, servers or entire infrastructure is gone basically giving you no chance of getting the password back. Well facing that scenario myself, I hacked around and found a work around.
First off I would not have figured this out if it wasn't for a similar post about bypassing the protection on the server available at http://www.sbsfaq.com/Lists/FAQs/DispForm.aspx?ID=23
The differences on the client side (compared with article above) start with the location of the file it's in C:\Program Files\Trend Micro\OfficeScan Client. Next the keys are a little different, first you need to find the [INI_CLIENT_SECTION] and in that file, change the following keys:

• Client_Allow_Uninstall to 1
• Client_Allow_Unload to 1
• Uninstall_Pwd to 70
• Unload_Protect to 0
• RemoveCTA to 1

Save the ini file and launch the uninstall. Now enter 1 as the password and viola it's gone! From a development point of view this is an example of how not to use encryption. The machine encryption in the patterns&practises Enterprise Library is a much better place to start, and in addition you should also look into using hash to sign files like this, so that tampering with them, invalidates them and requires an update from the server.

Vista has a great feature called complete backup with makes a VHD of your hard drive (more details see channel 9: http://channel9.msdn.com/Showpost.aspx?postid=229767), or so I'm told. Yesterday was the first chance I got to sit down and use it, and I'm not over the moon by it. I used an external SATA drive (connects via USB) to store the backup and that was fine. It didn't run the first time cause the laptop was on battery mode (probably a good thing that it warned me).
The VHD was created in an acceptable time and I moved to the new machine and popped the Vista disk in and started the restore. That was quick. However when I tried to boot it blue screened. So I popped the Vista disk back in and tried to use the startup repair tool, it said ti found a problem but couldn't repair it. So in the end I installed Vista over the restored version, which has it's plus in that it meant any files out side of the My documents of the user also got copied across but meant cleanup of the Windows.Old folder.
Looking around this morning it seems there are some issues in it

• http://techrepublic.com.com/5208-10877-0.html?forumID=102&threadID=210131&messageID=2163410 (some minor things to be aware of)
• http://professionalinsight.net/VistaBackup.aspx (didn't have this issue and the drives were very different)

To be fair thought some people have good luck with it, like this guy: http://coolthingoftheday.blogspot.com/2007/11/vista-complete-pc-backup-it-winner-in.html

In MSCRM 4.0 you can specify how the user works with their incoming and outgoing email. Incoming is none, the router, outlook client or the forward mail box while outgoing is the router, outlook client or none. There is two ways to config this, one get the user to set it in their settings (yeah right) or go through the users in the admin side, manually, one by one (boring and a waste of time). Well you can create a simple workflow to do it bulk:

• Step 1: Create a new blank workflow and set the entity to system user (despite my picture). http://www.sadev.co.za/files/user1.png 
• Step 2: Turn off the automatic options (well maybe, you may want this to run on create so future users also are set right). Click "On Demand" under available to run. Add a step to update the user. http://www.sadev.co.za/files/user2.png 
• Step 3: Click the set properties and update the "Email Access Configuration" to your preferred method. http://www.sadev.co.za/files/user3.png
• Step 4: Save your work flow and now click the "Run Workflow" button on the user list and select your workflow and click OK. http://www.sadev.co.za/files/user4.png

And voila now you have the users updated to the correct method. Another nice option for the network admins is once you installed the email router the ad users and groups has a menu option to launch the config tool for them (see http://www.sadev.co.za/files/ad.png)

When configuring the MSCRM 4.0 email router for Exchange incoming you may get the following message when testing: Incoming Status: Failure - The remote server returned an error: (403) Forbidden.

This is actually caused by a bad UI (IMHO) which kinda gets you to configure it wrong. What has happened is that the outgoing has a tick box saying to use SSL and asks for a server name, while the incoming asks for a URL. It automatically puts in http:// so naturally you fill in your server, i.e. http://myexchange

However Exchange runs on SSL so it actually needs to be https://myexchange

If that doesn't help then open up the URL you are putting in, in a web browser and see if it works. You'll get a lot more information on the real cause.

In MSCRM 3.0 I did a few redeployments of MSCRM and what was nice was in the database was the license table which contained the key. This was great since most of the time the customer couldn't find the original media a year down the line.

Well for MSCRM 4.0 the license table is gone, but fear not you can still get the key. If you have the media the key is in a file called license.txt (atleast according to the implementation guide). If you got the download version there is no such file but you can still get it from the MSCRM_CONFIG database in the ConfigSettings table.

Static analysis is the process of having a tool scan at your compiled and/or uncompiled code for things like bad practises, maintainabilty, performance and security issues and so on. If you have Visual Studio Team Edition or better then you have the built in tool which is based on the free FxCop. Wikipedia contains a nice list of various tools available, but the reason why FxCop/VS is so much better is the help on the issues. All the help contains samples and information on the how and why of the problem and solutions for it. This actually becomes more than a tool to ship software but a great learning aid for the developer using it.

There is an interesting site called spock which you put your name in and it finds details about you. Seems very poor results for anyone beside the brits and the yanks (aka the rest of the world!) but once I put in South Africa it did find one thing about me.

Long running comment with people I know is the one "There is blood in my alcohol stream" (sometimes changed to "There is blood in my coffee stream"). Anyway someone finally proved it is possible, albeit that it is scary that it was only found out because she was driving at the time (or passing out while driving). More on her at http://seattletimes.nwsource.com/html/localnews/2004094566_webdui27m.html (via http://blogs.msdn.com/oldnewthing/archive/2008/01/02/6950841.aspx).

Subjects in MSCRM are this interesting tree view structure which allows you to associate cases, kb articles and products in interesting ways. However they have never been customizable, which has limited the usefulness of them, in addition to a few interesting limitations they had. Well MSCRM 4.0 takes two steps forward into making subjects useful, namely:

• You can now delete used subjects. In MSCRM 3.0 once you used a subject it was locked and could never be deleted, even if you updated all your cases etc... to another one. This made management of the tree a nightmare since it basically meant that you got one chance. In MSCRM 4.0, provided nothing is currently associated to the subject, you can delete it. If you try and delete one and it is associated you'll get an error message, simply fire up advanced find and remove/update the linked items and you will be able to delete the subject!
• You can now associate subjects to other entities! But not with the full MSCRM 4.0 power. In fact the only thing is a one to many (1:N) relationship (see attached screen shot), many to one (N:1) and many to many (N:N) are not available. This means that your custom entities or system entities can now use the main subject tree too!

It's still not where it needs to be, namely support for multiple subject trees, customization support (even just adding attributes would help) and better display showing the full structures (ala X > Y > Z) but it is now much more usable than before.