Minimal copy of instance and what the result is.

We've been working a bit with migration the past couple of weeks and in this job we've done a few instance copies using the "Minimal Copy Instance" from the Administration center. This resulted in a sandbox instance with 4.5 GB of data which seemed sort of funny.

What we were doing is to copy the production instance to a sandbox dito with the minimal copy instance option from the Administration center. According to the documentation from Microsoft found at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/admin/copy-instance  the entities that are copied are the following:

• BusinessUnit
• ConnectionRole
• Currency
• DuplicateRule
• DuplicateRuleCondition
• EmailServerProfile
• FieldPermission
• FieldSecurityProfile
• ImportMap
• InternalAddress
• Mailbox
• Organization
• Position
• Report
• Resource
• ResourceGroup
• Role
• RollupField
• SavedQuery
• SLAKPIInstance
• Solution
• Subject
• Team
• TeamTemplate
• Template
• SystemUser

Now, I had a look at the storage report of the instances and we have three of those, one development, one test and one production. These are 1.5GB, 4.5GB and 8.5GB which is sort of interesting since the test one should be completely empty of data.

Digging deeper into this I had a look at what data is present and there's quite a lot of Audit logs according to the admin center, 850 MB of those, but when I look at the Audit logs in the instance, there's 250MB that I can find. Looking at the Entity list, Audit logs aren't present there making it even more confusing.

The top three biggest tables are contoso_paymentBase, ContactBase and AuditBase (contoso_paymentBase is called something else really, but it's a custom entity, or the "contoso_payment" is a custom entity at least). Now, these tables should be the SQL tables of the entities "contoso_payment", "Contact" and "Audit", but how can they be so large considering there are NO records in the first two and yes, 250 MB in the Audit table which I can see, but not 800 MB.

I started a support case with Microsoft in this matter at the first contact I was told that I should do a reset of the instance, which isn't really what I want since I want the metadata presented above plus all customizations, Microsoft was going to investigate and come back to me.

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se 

SSIS error: The Binary Code for the Script is Not Found issue on SQL server

Hey, long time no see. (if you're reading this). It's been quite hectic the past 6 months so I haven't been doing much blogging as you might have noticed but now it's time again. This time not really Dynamics 365 but related as integrations are one major thing I'm doing.
I've been working on an integration using SSIS for some time now and we've finally gotten to the point that it's time to push to production. Then this error appeared.

To sum things up rather quickly, I have two packages that handles integration, one per source system, and they read customer info and purchase info which our customer wants to see inside CR... eehhmm, Microsoft Dynamics 365 Customer Edition (powered by powerplatform?). I will go through my steps but the solution is really at the end of the post so, by all means scroll down.

They both worked when I run them in Visual Studio in "debug mode" and the first one worked very good when deployed to the SQL server which will orchestrate the integration.

When I deployed the second package I got a validation error saying "The Binary Code for the Script is Not Found" and then it pointed to a script component in the package saying "script component[5212]" (Yes I was lazy and didn't name it after what it did, which was bad it would seem). I did what most developers do, search the internet and there are quite a few hits on the error.


As you can see, I visited most of these but it didn't really help since most of them are addressing issues when running the packages inside Visual Studio and that wasn't really my issue since it was working in Visual Studio but not on the SQL server. These are all saying roughly "do something in the script code, recompile the script and then recompile the package" with a few variants talking about pre compiled code which doesn't seem to be a factor any longer.

Eventually I deleted the script component and recreated the script component, which of course made the entire package misbehave since you're not supposed to do changes to an SSIS package it seems.
This didn't resolve anything either, one thing I did see though is that the script component ID in the error message didn't match the ID of the component in the package which looked sort of strange.

Next step was that I created a new solution, imported the package and compiled it. At this point I was sort of thinking that it was silly to have the same name of the packages when they had the same solution so I renamed the package file, again I was lazy and just let it be called package.dtsx.After a move to the server and installation of the package it validated and ran just fine.

Solution: Don't be lazy and name stuff to what they are doing. Lessons learned: Error messages in Microsoft's products aren't always brilliant, even outside Dynamics.

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se