Out of the same interview as before, comes another article. I like this one more, as it feels less sales like (for those who know me, know I am not a sales person) and more like the actual interview was.

Ages ago I did an interview around the Rezonance product brand I work on. It was so long back I had forgotten about it. Well the interview appeared online this weekend. Thanks to Carey for the heads up.

Update 26 August 2010: A new and better version of this Excel file has been made available. Please go to South African ID Number Checker in Excel version 2 to get it.

Update 11 August 2011: Want this as an app for your smartphone? Click here

A few days back I wanted to validate a list of ID numbers, and previously I have done the basics (length, date etc...) but I decided to do the full thing this time. So I search for the rules and found this post, which explains it nicely and contains some C# code. However for me C# didn't cut it as I wanted to process an Excel spreadsheet. So I whipped together a nice one which does the following checks:

• Length
• Valid Date
• Date is in the past
• Gender Flag
• Nationality Flag
• Check Bit

I've hidden the calculation cells so you can just unhide if you want to see the calculations. When I ran my list through it the failures came in two forms, obvious failures (things like 1000000000000) or check bit failures. Since I don't know which are real/valid in my list I am not sure if the check bit is 100%, but it did work fine for real ones I put in myself.
Anyway you can grab it below in the attachments section (You can grab the version 2 from the link above).

24 Jan 2010: I have disabled comments on this post as I am getting a lot of people asking me about who ID numbers belong to, how to track people based on ID's or what someones ID is. None of those I can answer as I do not work for the govt, police etc... If you have questions on the technical aspects of ID numbers please contact me using the contact form option.

UPDATE 11 Feb 2008: The offical tool is now out. See http://www.sadev.co.za/node/167. The download for the beta one has been removed.

If you go through the documentation for MSCRM 4.0 there is a tool which can do the configuration of for you. However this tool does not exist yet and to get it you need to speak to Microsoft Product Support Services as it is still beta. However from looking at the news groups it seems thats hit and miss (guessing that some of the support guys know about it and some don't as it is beta). So until it is available I am putting it up here.

NOTE: This is a BETA tool and neither Microsoft nor myself will give you any help on this. This tool could completely damage your system so if you don't trust it, then do the steps described in the documentation.

Update 23 June 2008: See The official way to change MSCRM ports for an official way to do this. Update 12 March 2008:

• 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 different address family from 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 sit 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 even though you access your server on a specific URL, internally in the Async service (which handles the workflow, duplicate detectionand imports) and the email router and outlook client actually just use the URL you used to connect to the Discovery Service.

The discovery service is a web service which gives back the real URL to the web services in MSCRM, so if you changed IIS it still gives back the old ones. There is also a bug in the RTM of MSCRM 4.0 which causes it to use the machine name instead of the host header after upgrades. So you go to http://<nice name> and the discovery service gives back to http://<machine name>/mscrmservices/2007/crmservice.asmx which doesn't exist since yourhost 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 though this with Microsoft PSS and they came back with a SQL command you can run to fix this.

NOTE: As this is a DB change it is unsupported. If you are a little worried about the impact do backups then try 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 do an IISReset and restart the Async service and everything should start to work fine! As I said before this came from PSS (in particular Justin Thorp)and I would really like to thank him for the hard workand great responses I got on it.

The following error message is likely the least thought out requirement of MSCRM 4.0 and a common cause of frustration for developers in enterprise customers who are using the multi-tenancy features.
 0x80040256
 Not have enough privilege to complete Create operation for an Sdk entity.
 Platform
You get this error during an attempt to register a workflow activity or plug-in into MSCRM 4.0, and you may think that to do this customisation you need atleast the System Customizer role. Well you are wrong, you need higher than that. In fact the highest role for an organisation (System Administrator) isn't even enough. You need to be Deployment Administrator. This role is assigned on a server level, in the Deployment Manager tool and gives that user full powers on all organisations!
The reason I think this is badly thought out, is three fold. Firstly, I do not want to enable developers to see certain things in MSCRM in live enviroments (thus the great System Customizer role) but I want them to do the customisations. The second is if I have a developer working in a certain division or group company with it's own MSCRM organisation, I really don't want to let that developer loose on other organisations on the server (security and stability reasons). Lastly I don't want to have to give access to the server to more people than absolutely needed, and as I now need to be able to set people up to be Deployment Administrators from time to time it means extending that group of people. Anyway heres hoping MSCRM 5.0 will fix it ;)

Remote debugging sounds like the title to a book but it isn't - in truth, I have never used remote debugging because haven't needed to. In MSCRM 3.0 the exceptions bubbled up nicely in workflow and I could do a lot on my own machine. However in MSCRM 4.0, those exceptions don't bubble up nicely :( All you get is something like this:

Beside's adding logging to your assembly (which you should do anyway), what's a dev to do now? You can now debug your plug-in's and custom workflow activities using the remote debugging facility in Visual Studio and that's what I hope to show in the next 9 easy steps!

1. On your machine you'll find a folder <system drive>\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger (assuming you installed Visual Studio 2008 to the default location) which contains an x86 folder. Copy that to the MSCRM server and run the msvsmon.exe file.
2. Now click Tools -> Permissions and give yourself access to it.
3. Now load you plug-in or custom workflow activity (when I refer to plug-in for the rest of the document it means both, unless otherwise stated) using the *cough*annoying*cough* plug-in registration/developer tool.
4. Next copy the PDB file for your assembly to the <system drive>\Program Files\Microsoft Dynamics CRM\Server\bin\assembly (assuming you installed MSCRM 4.0 to the default location).
5. Now to finish up the MSCRM server side do an IISReset and restart the Async Windows Service.
6. Back on your machine now in Visual Studio, set a break point in your code.
7. Next click Debug -> Attach to Process. The transport should be Default and the Qualifier should be <domain>\<username running msvsmon.exe on the server>@<Server name>. Note: You can get this from the Tools -> Options in msvsmon.exe. You may need to do some firewall configuration but it should be automated.
8. Next select the process to attach to, for an online plug-in, attach the debugger to the w3wp.exe process on the Microsoft Dynamics CRM server. For an offline plug-in, attach the debugger to the Microsoft.Crm.Application.Hoster.exe process. For asynchronous registered plug-ins or custom workflow activity attach to the CrmAsyncService.exe process.
9. Now do whatever is needed to trigger your event and watch Visual Studio on your machine do it's magic!

The workflow configuration tool is a great tool in the SDK which you build. It creates a couple of assemblies and and nice installer. You then run that and it puts the add-in into visual studio 2005, which I don't use anymore :( So I have updated it for Visual Studio 2008: The changes to do it were:

• Add the missing sdk proxy assembly to the files for the installer.
• Set the directory for the templates to the Visual Studio 2008 one.
• Changed the version of the assembly from 8.0 to 9.0 in the CRMWorkflowAddin.AddIn file.
• Change the title to show it is specially for Visual Studio 2008
• Changed the product ID so that it is not confused with the semi-offical one in the SDK.

You can download the actual installer files here and the updated deployment project file (in case you want to check) here.

Note: This is based on the first public release of the Microsoft CRM 4.0 SDK. If newer versions come out, you maybe better off using those versions. I'll (try) keep this one up to date.

Update 16 Jan 2008: This tool doesn't add the MSCRM workflow actvities which are available. To add those to the tool box see this post.

It seems that my stupid tips is catching on, however I did not expect this level of duh from the official MSCRM blog itself. The post states that you can use .Net 3.5 for development as it uses the same CLR as .Net 3.0 (which MSCRM 4.0 is based), however they don't recommend it because it could break if .Net 3.5 isn't installed. Duh! Does that mean that I should not use .Net 3.5 at for any dev since I can't guarantee that it will ever be available on a machine?! How about not using Windows cause I might write code and then there is a Linux box that exists. *sigh*
They should have said if you write code in .Net 3.5 and it breaks because it's not installed and you can't figure it out, then you need to stop writing code and become a chef or something and leave the dev to the people with at least a double digit IQ.

Two stupid tips when using it (it's duh if you think about it, but anyway I did it):

• Don't try to create a new organisation when installing Windows updates, especially if there is a SQL update in there which stops the SQL server.
• Don't run multiple copies of the deployment manager to create multiple organisations at the same time.

If I do anything else duh with the deployment manager I'll be sure to let you know.