Many BizTalk Server features still suffer from poor documentation. Worse, a lot of what you find online is outdated. Microsoft BizTalk Accelerator for RosettaNet (BTARN) is a perfect example.
Today, I tried to extend BizTalk Server 2013 Accelerator for RosettaNet with a new inbound Partner Interface Process (PIP) schema. During the setup, I hit an error in Event Viewer:
Source module:
RNDisAssemblerCorrelation information:
Description:
Receive pipeline rejected incoming message due to the following RNIF exception:
UNP.SCON.VALERR: A failure occurred while validating the service content.Details:
The document specification <MyNamespace.MyPIP> from assembly <MyAssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=…> failed to load. Verify the schema for this document specification is deployed and is in the Global Assembly Cache.
Note: this same error can occur in previous or new versions of BizTalk Server.
Based on the received error and according to a possible cause described by Microsoft at Troubleshooting: Microsoft BizTalk Accelerator for RosettaNet Issues and Resolutions, either the document namespace or the root node property of the deployed schema for the instance that you are trying to extend is incorrect.
In fact, this could be the issue, but I found it really odd because in the error details, my DLL, containing the schema that I was trying to extend, was being properly referenced; nevertheless, I confirmed that it was properly deployed… But as I suspected, this wasn’t my problem.
Note: this behavior does not happen with PIP that is included out-of-the-box with BTARN (in the Microsoft.Solutions.BTARN.Schemas.RNPIPs DLL) only with new ones and only in the incoming process.

Fortunately for us, I found an article from Nick Heppleston that mentions in his blog that:
“RN Disassembler does, in fact, attempt to validate the message contained within the Service Content against a deployed schema, just like the standard XmlDisassembler. The message that our trading partner was sending did not validate, and hence the RosettaNet Accelerator threw this error message; once we had corrected the schema and redeployed, the error went away.
This is certainly one to be aware of if you are developing custom PIP’s to use with the RosettaNet Accelerator: ensure that the message in the Service Content validates against your custom PIP schema.”
Again, this wasn’t my problem because the Schema was properly deployed in the system. I only mention this because it is important for understanding how the BTARN engine/processes work.
📝 One-Minute Brief
If BTARN rejects an incoming custom PIP with RNIF UNP.SCON.VALERR (“failure occurred while validating the service content”), the schema may be fine. The real cause is often IIS: BTARN app pools run on .NET v2.0 by default, while newly generated PIP artifacts target .NET 4.x. Set BTARNAppPool (and BTARNHttpReceivePool) to .NET v4.0 and enable 32-bit applications, then retest.
Cause
By default, BTARN App Pool Settings are configured to use .NET framework 2.0, which doesn’t enable 32-bit applications, and the application pool is in Classic mode

Important for you to know is that the accelerator requires both an in-process and out-of-process host, both of which must be marked as Authentication Trusted and 32-bit only.
To run the BTARN End-to-End scenario, you need two important things:
- Enable the BTARN Application Pools for 32-bit.
- Add an HTTP Handler for *.dll referring to the IsapiModule Filters.
But what I found today is that when you want to extend BTARN with new incoming PIP’s, the artifacts generated are going to be .NET 4.0/4.5 unless Visual Studio is configured to do otherwise, which we really cannot control using BizTalk projects:

This means, along with setting the application pools for the 32-bit, the .NET settings must be set to match.
Solution
To solve this issue, you must:
- Type Internet Information Services (IIS) Manager or IIS in the Windows Start screen and click on the Internet Information Services (IIS) Manager option on the Apps menu.
- Expand the server and click on Application Pools to display available application pools in the center panel.
- Right-click on BTARNAppPool and select Advanced Settings.
- On the Advanced Settings window:
- Change the value of .NET Framework version from v2.0 to v4.0.
- Change the value of Enable 32-bit Applications from False to True.
- And then click OK.

Advice: You should do the same for the BTARNHttpReceivePool application pool.
After I fixed these configurations, I was able to successfully receive the PIP message from my external Partner.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.