MS CRM 4.0 VPC - remove the 'crm' host header

On the CRM Demo VPC 2009, there is a host header 'crm' defined to redirect to the crm-srv-01:5555 website (the CRM application). When you want to change this, you'll need to do this steps:

- Change the host header in the Internet Information Services window. Select Properties on the CRM Web site, go to the Web Site tab and click Advanced. Hit Edit... and remove the 'crm' host header value

Because you removed your host header, the workflows won't work anymore, because the configured webservice url still points to the host header value. Perform these steps to change this:

- Change this Registry keys in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM: ServerUrl to http://localhost:5555/MSCRMServices; LocalSdkHost to localhost; LocalSdkPort to 5555

- Go to the SQL Server Management Studio, and execute this queries on the MSCRM_CONFIG database (This is not supported! Please take a backup of this database before executing the queries):

USE MSCRM_CONFIG

Update DeploymentProperties SET NVarCharColumn = 'localhost:5555' WHERE ColumnName = 'AsyncSdkRootDomain'

Update DeploymentProperties SET NvarCharColumn = 'localhost:5555' WHERE ColumnName = 'ADSdkRootDomain'

Update DeploymentProperties SET NvarCharColumn = 'localhost:5555' WHERE ColumnName = 'ADWebApplicationRootDomain'

(queries found on http://www.sadev.co.za/content/workflow-doesnt-work-imports-never-happen-emails-dont-flow-and-outlook-clients-cannot-connec)

- Perform an IISRESET and Restart the Microsoft CRM Asynchronous Processing Service.

Microsoft Dynamics CRM 4.0 - enable tracing / logging

To enable logging on your Microsoft Dynamics CRM 4.0 server, you can follow this instructions: http://support.microsoft.com/kb/907490/en-us. A handy tool is written to do this instead of changing the registry keys yourselve: http://blogs.msdn.com/benlec/archive/2008/03/04/crmdiagtool4-for-microsoft-crm-4-0-has-been-released.aspx.

However, the tool configures your server to log all the stuff it's processing. This is because the registry value of TraceCategories is set to "*:Verbose". Set the registry value to "*:Error" if you only want the errors to be logged. If you want to log errors and warnings, set the value to "*:Error;*:Warnings".

The default location is set to [drive]:\Program Files\Microsoft Dynamics CRM Server\Trace. To change this, change the value of the TraceDirectory registry setting.

Sharepoint - An update conflict has occurred, and you must re-try this action.

I got this error today on a restored MOSS environment, when trying to add an existing content database:

An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=WEBAPPLICATIONNAME Parent=SPWebService is being updated by DOMAIN\USER, in the w3wp process, on machine SERVERNAME. View the tracing log for more information about the conflict.

I found this KB to solve this issue: http://support.microsoft.com/kb/939308

"This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server."

Sharepoint - An update conflict has occurred, and you must re-try this action.

I got this error today on a restored MOSS installation, when trying to add an existing content database:
An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=WEBAPPLICATIONNAME Parent=SPWebService is being updated by DOMAIN\USER, in the w3wp process, on machine SERVERNAME. View the tracing log for more information about the conflict.
I found this KB to solve this issue: http://support.microsoft.com/kb/939308
"This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server."

Sharepoint - An update conflict has occurred, and you must re-try this action.

I got this error today on a restored MOSS installation, when trying to add an existing content database:

An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=WEBAPPLICATIONNAME Parent=SPWebService is being updated by DOMAIN\USER, in the w3wp process, on machine SERVERNAME. View the tracing log for more information about the conflict.

I found this KB to solve this issue: http://support.microsoft.com/kb/939308

"This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server."

Operating system error 1330(error not found) on RESTORE DATABASE in SQLcmd

A colleague of mine had this problem today (and found a solution!):

While trying to restore a database from a UNC path that’s not in the same domain as your database server, you might get the following error:

1> RESTORE DATABASE DatabaseName FROM DISK = '\\Server\Dump\DatabaseName.bak' WITH REPLACE

2> go

Msg 3201, Level 16, State 2, Server ServerName, Line 1

Cannot open backup device '\\Server\Dump\DatabaseName.bak'. Operating system error 1330(error not found).

Msg 3013, Level 16, State 1, Server ServerName, Line 1

RESTORE DATABASE is terminating abnormally.

Error not found, quite handy.

Note that on that network share “Everyone” has read rights (also on NTFS). So the file can be read from explorer. SQLcmd tries to use the domain user, and only that user for some reason.

The solution lies in the creation of a user account on the non-domain machine, with the same name as the domain user. (Never mind the domain prefix). Set the password, and you’re off!

SharePoint Dispose Checker Tool

"SPDisposeCheck is a tool to help you to check your assemblies that use the SharePoint API so that you can build better code."

http://code.msdn.microsoft.com/SPDisposeCheck