Workflow doesn't work, Imports never happen, emails don't flow and Outlook clients cannot connect
Update 12 March 2009:
- An easier way exists to do this now. See Workflow doesn't work, imports never happen, emails don't flow and Outlook clients cannot connect - Reloaded
- Another issue causing the same problems has been found and solved. See: Request IP address has a different address family from the network address.
After you get MSCRM 4.0 up and running (install or upgrade) on your system with a custom host header, you may find that workflow doesn't work (or flow), imports stay in a submitted state forever, the email router and Outlook client cannot connect to the MSCRM server. This could also happen if you change the website details in IIS.
What is happening is that, even though you access your server on a specific URL, internally the Async service (which handles workflow, duplicate detection, and imports) and the email router and Outlook client actually use the URL you used to connect to the Discovery Service. The Discovery Service is a web service that returns the real URL to the web services in MSCRM, so if you change IIS, it still gives back the old ones. There is also a bug in the RTM of MSCRM 4.0 that causes it to use the machine name instead of the host header after upgrades.
So you go to http://<nice name>, but the Discovery Service gives back http://<machine name>/mscrmservices/2007/crmservice.asmx, which doesn't exist since your host headers should have it as http://<nice name>/mscrmservices/2007/crmservice.asmx. You can pick this up using Fiddler on the email server or desktop machine when trying to configure the email router or Outlook client, respectively.
So I went through this with Microsoft PSS, and they came back with a SQL command you can run to fix this. NOTE: As this is a database change, it is unsupported. If you are a little worried about the impact, do backups before trying it. If you are very worried, contact PSS directly for help.
USE MSCRM_CONFIG
UPDATE DeploymentProperties SET NVarCharColumn = '<server>:<port>' WHERE ColumnName = 'AsyncSdkRootDomain'
UPDATE DeploymentProperties SET NVarCharColumn = '<server>:<port>' WHERE ColumnName = 'ADSdkRootDomain'
UPDATE DeploymentProperties SET NVarCharColumn = '<server>:<port>' WHERE ColumnName = 'ADWebApplicationRootDomain'
Example: If your server is called myserver and runs on port 50000:
USE MSCRM_CONFIG
UPDATE DeploymentProperties SET NVarCharColumn = 'myserver:50000' WHERE ColumnName = 'AsyncSdkRootDomain'
UPDATE DeploymentProperties SET NVarCharColumn = 'myserver:50000' WHERE ColumnName = 'ADSdkRootDomain'
UPDATE DeploymentProperties SET NVarCharColumn = 'myserver:50000' WHERE ColumnName = 'ADWebApplicationRootDomain'
Once done, run an iisreset and restart the Async service, and everything should start working fine! As I mentioned before, this came from PSS (in particular Justin Thorp), and I would really like to thank him for the hard work and great responses I received on it.