The CRM Grid – A Microsoft CRM Blog

Greg Owens’ rose-tinted MS-CRM mumblings

Archive for January, 2008

Bulk removal of “Primary Contact” field – not as easy as you’d think!

The concept of “Primary Contact” does not fit well with our business model. As a result, the “type” of contact that was being populated in that field varied widely – anything from MD to chief bottlewasher had been placed in there.

Suffice to say, it was agreed with the business that the solution to this was to rename the field to “Customer Service Contact” and flush the old data in that field. No problem – a two-minute job. Or so I thought.

My intended approach was to conduct an Advanced Find, then use Bulk Edit to remove the value from the lookup. No such luck – the net effect was that the CRM Application concluded I had made no change, looked at me quizzically and sniggered when I clicked on save.

The second approach is one I’ve used before: combine an Advanced Find with a temporary Manual Workflow rule to update a number of records at once. Curiously, “Primary Contact” is NOT a field that is available for the Update Entity action in CRMv3. How frustrating – I didn’t much fancy spending extended “quality time” with my CRM system, then going through all those records and manually deleting them. And frankly the idea of donning my surgical gloves slicing into the MSCRM database wasn’t too appealing either.

The successful solution? I created a temporary Contact “I-Am-Not-A-Real-Person-Prentend-Im-Not-Here”. I then used Bulk Edit to assign the Primary Contact field to use this new Contact. Finally, I expunged my Contact record, leaving the Primary Contact field fresh, clean and ready start its new life as a “Customer Services Contact” field.

One thing can be said for v3 – it often forces you to think more innovatively!

The underlying connection was closed: unable to connect to the remote server

Our MS-CRM deployment has a fairly simple, custom integration with our mainframe system. Nothing fancy, effectively just shunting XML files around to perform overnight and the occasional ad hoc data sync.

We farmed the coding out to a well-known implementation partner and received code which had been tested in their development environment. A little reconfiguration and we were good to go. The first few test files worked just great, so I started throwing some bigger files at it. Suddenly we were getting problems…

“The underlying connection was closed: unable to connect to the remote server.”

Strange – this hadn’t been seen in the development environment. The connection details were clearly correct too since half of the batch had been processed ok. There was little else to go on. Now we all know, usually Google Is Your Friend, but on this occasion all we could find were details of generic ASP.Net web service development issues almost exclusively caused by firewall and proxy issues – again, this couldn’t be the case since the batch was partway complete.

The developer was at a loss – he had done nothing out of the ordinary. We noted that the service would fail at roughly (though not exactly) the same point each time, so his only suggestion was to introduce forced delay between each call to the CRM WebServices. This was far from satisfactory, but fundamentally it worked (and we’d already exceeded allocated time on this simple service) so that was that.

Unfortunately I’m a persistent little bugger, so I couldn’t rest knowing there was an issue out there that we hadn’t identified! What seemed apparent was that this network issue was not at the transport layer or lower. I’m not a hardcore developer, but I remember that network ports can be opened/allocated on a dynamic basis. Don’t berate me but I think this is what is meant by “ephemeral ports”. Suffice to say, this seemed to fit the scenario – the server was running out of dynamic ports (or connections) to allocate to our batch service.

Anyway – I guess that that’s mostly just hot air: if you’re reading this post, there’s a good chance you’re having the same issue. The cause? It is acknowledged in Microsoft’s KB article: KB913515, but unfortunately you’ll need access to PartnerSource or CustomerSource to view.

The fix is made with a couple of changes to the registry to amend the machine’s TCP/IP configuration. If you can’t access the KB article above, I reckon I can probably point you to one of Microsoft’s publicly available pages which explains “WinTCP TIME-WAIT Delay”  (Win2k version here) and why you might need to amend the TcpTimedWaitDelay and MaxUserPort keys in the registry.

Please comment and let everyone know if this helped 🙂

Crikey… 2 months gone already?

Well, there was a deadline at work, then Christmas came and went, then there was new year and finally there’s been all sorts of fun and games the last couple of weeks (which I hope to post some exciting news about in the next few days) – but I hadn’t realised it had been so long since I last posted!

It seems there’s not a lot of new v3.0 postings being made now that v4.0 has emerged screaming; all pink and wrinkly. I have a few more things I want to share before v3.0 becomes old news 😉