Dynamics CRM 2016 and Legacy Entities

This is not the first time I've run into a problem with so called "Legacy Entities". I am referring to the entities that have been left out in the cold since CRM 2013. These include

• address
• opportunity product
• quote product
• order product
• invoice product

There are some things that these entities don't support which include

• Accessible in the Tablet App
• Update attributes with workflows
• Business Rules (though oddly Opportunity product does support business rules)
• Old style forms

I have also come across with problems when upgrading to CRM 2016. This problem occurred on Opportunity Products form which had been customised in CRM 2015. I removed a number of fields I didn't need and it was working fine. 
After the upgrade to 2016 though I was getting this JavaScript error on form load

Field:window
Event:onload
Error:Unable to get property 'addOnChange' of undefined or null reference

Now that was not from any JavaScript code that I had but from a Microsoft library called OpportunityProduct_main_system_library.js

When I looked into the code I could see that it was referring to attributes that were not on the form:
Manual discount amount
Tax

When I added these back onto the form and hid them, the error went away. 

Moral of the story: Don't delete attributes from legacy forms - just hide them. 

Dynamics CRM 2013 Microsoft Web Page Dialog error

If you use Dynamics CRM 2013 for any length of time then you will have noticed the Microsoft dialog box that pops up intermittently.  It seems to occur randomly and is hard to reproduce.  As far as I can see it doesn't result in any data loss so I just ignore it.

But the screen is irritating and doesn't give a good impression to first time users.

It can be disabled by logging on to CRM as the System Administrator and going to Administration and Privacy Preferences. On the Privacy Preferences dialog click the Error Reporting tab. Select "Specify the Web application error notification preferences on behalf of users" checkbox and then select the radio button "Never send an error report to Microsoft".

The errors are still happening but at least the screen isn't popping up. 

BizTalk Receive Location Error - Verify the schema deployed properly.

I was getting an error with Biztalk Server when receiving a file from MSMQ although you get a similar error on FILE receive locations. The message was

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Receive Port: "Portname" URI: "FORMATNAME:DIRECT=OS:.\PRIVATE$\QNAME" Reason: Finding the document specification by message type "RootNode" failed. Verify the schema deployed properly.

It is caused because the message does not conform to a schema that Biztalk recognises, in my case because the RootNode is not recognised. The problem is BizTalk has not saved the original message. It's gone. The method described here shows how to keep a copy of the original file. There maybe other solutions but this works well for me.

The solution I outline is for FILE ports but once you understand the principle you will see how to apply it for MSMQ. The principle is to use a Receive Location and a Send Port Group configured for the Pass Through pipeline.

The Receive Location becomes the new port which polls for inbound messages that arrive in the directory c:\inbound. The Receive Location is bound to a Recieve Port which I'll call ReceivePort1.

The Send Port Group has 2 Send Ports in it. Both Send Ports, for the sake of simplicity, are FILE ports that are configured to write out the file using %SourceFileName% to the following directories c:\filecopy and c:\biztalkinbound. Both are configured to use the Pass Through pipeline.

Got to the Filter on the Send Port Group and add the following filter
BTS.ReceivePortName == ReceivePort1

Enable the Receive Location and start both Send Ports and the Send Port Group. If you drop a file into c:\inbound it will appear in both directories c:\filecopy and c:\biztalkinbound and it will retain the original file name.

Your original Receive Location should now point to the location c:\biztalkinbound and it will be configured for whatever pipeline you were using (XML Receive or a custom Flat File pipeline).

The benefit of this is you always have a copy of the original file in its original format in the directory c:\filecopy. As an added treat I got my orchestration to delete files that were successfully processed from this directory. So c:\filecopy became the place which stored files that failed to be processed - the classic being that they failed to match the correct schema as described by the error at the beginning of the post. Send an email alert to the Sysem Administrator and you'll be a hero.

Invalid handle error in Visual Source Safe

I was getting an "Invalid handle" error message the other day when trying to access Visual Source Safe and it drove me mad for a couple of days until I found a solution. So I thought I would blog it in case you run across the same problem.
I was at a customer site using my laptop which was not connected to the customer's domain. When I plug in the network cable I get issued an IP address from their DHCP server. I then fire up my Virtual Machine with my development environment on it including Visual Source Safe 2005. The virtual machine network connections are configured so that it too is issued an IP address from the customer's DHCP.
Using the logon credentials the customer has issued me, I can connect to servers and file shares on their domain.
Now the Visual Source Safe database was located on one of the customer's servers and I noticed that the network connection was unreliable. At times when I pinged the server I got "request timed out" or "host destination unreachable". The result was when I opened Visual Source Safe sometimes it would work just fine and other times it would give me the "Invalid handle" error. It got to a point where I was unable to connect to Source Safe for several days.
The solution as it turned out was quite simple. I mapped a drive letter to a network share on the VSS server. Note it's important to map a drive letter, just using "Run" to connect to the share was not enough. Now of course if you can't even ping the server then mapping the drive won't work either. But I found that once I was able to map the drive the "Invalid handle" error would go away - at least for the rest of the day. I still find that each day I need to disconnect the drive and then reconnect but it's a small price to pay to have access to VSS for the rest of the day.
So if you come across the same situation I hope this helps you to solve it.