BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt) fixed by July 30, 2018 Microsoft Security Updates

BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt) fixed by July 30, 2018 Microsoft Security Updates

Last month I wrote a blog post regarding the “An internal failure occurred for unknown reasons (WinMgmt)” error in the BizTalk Server Administration Console caused by the July 10, 2018 Microsoft Security Updates, you can see the entire blog post here: July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt). In which I document a workaround to solve the following problem:

TITLE: BizTalk Server Administration

——————————

Failed to create a BizTalkDBVersion COM component installed with a BizTalk server.

Class not registered (WinMgmt)

——————————

BUTTONS:

OK

——————————

An internal failure occurred for unknown reasons (WinMgmt)

And based on that you wouldn’t be able for example to: restart the host instances from the BizTalk Server Administration console.

Happy to inform you that Microsoft already released a new security update that will fix this problem.

Cause

As official documentation (https://support.microsoft.com/en-gb/help/4345913/access-denied-errors-after-installing-july-2018-security-rollup-update) state: Applications that rely on .NET Framework to initialize a COM component and that run with restricted permissions may fail to start or run correctly after you install the July 2018 Security and Quality Rollup updates for .NET Framework.

Microsoft .NET Framework runtime uses the process token to determine whether the process is running within an elevated context. These system calls can fail if the required process inspection permissions are not present. This causes an “access denied” error.

After you install any of the July 2018 .NET Framework Security Updates, a COM component fails to load because of “access denied,” “class not registered,” or “internal failure occurred for unknown reasons” errors.

So, the cause of these problems was security updates that were released by Microsoft on July 10, 2018.

Solution

On July 30, 2018 Microsoft released new Security Updates https://www.catalog.update.microsoft.com/Search.aspx?q=4346877 that will fix these issues.

An internal failure occurred for unknown reasons (WinMgmt) fixed

To solve my problem, I:

  • Applied/installed all the possible available updates on my BizTalk Server machine;
  • I manually download and installed the Security Update marked in the picture above;

After I restarted my BizTalk Server machine, this problem was fixed.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Demystify Invalid type name error on BizTalk Schemas (Part II)

Demystify Invalid type name error on BizTalk Schemas (Part II)

In the last post, we try to demystify the reason and cause of the error: Invalid type name. The root node type has to be a valid C# identifier when you are working with a schema with a single root node.

In this second part of the post, we will address what happens If we are working with a schema with multiple root nodes, and two or more root nodes contains hyphens (-) or any other punctuation characters?

Let’s take the following example, where we have:

  • The root node “My-NAME-SANDRO” with the “RootNode TypeName” property set as “My-NAME-SANDRO”
  • And the root node “Let-SEE-What-happens” with the “RootNode TypeName” property set as “Let-SEE-What-happens”

BizTalk Schema: Invalid type name error

If we try to build our BizTalk Server solution within Visual Studio it will fail with the following errors:

Severity Code Description Project File Line Suppression State
Error Node “My-NAME-SANDRO” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1
Error Node “Let-SEE-What-happens” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1

BizTalk Schema: Invalid type name errors

Cause

Official Microsoft documentation state that The Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

And in this case – when working with multiple root nodes in a single schema – it is not allowed the use of hyphens or other punctuations like “.”, “!” and so on, with the exception for the underscore (_).

We saw in the previous post that we could work around this “limitation” in schemas with a single root node by open the Schema with XML (Text) Editor and fix the “rootTypeName” for the value you want. In this case, it will not work.

Solution

As hyphens, or any other punctuation characters, are not allowed, the only solution you have is to change it from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” or “My_NAME_SANDRO” instead of “My-NAME-SANDRO”
  • And for the node “Let-SEE-What-happens” the “RootNode TypeName” value can be “LetSEEWhathappens” or “Let_SEE_What_happens” instead of “My-NAME-SANDRO

By removing all hyphens, or any other punctuation characters, from this property in all schemas you will guarantee that you will not face this issue again at least in this project.

Conclusion

As a best practice you should use hyphens, or any other punctuation characters in the “RootNode TypeName”, nevertheless:

  • The use of hyphens or any other punctuation characters is allowed in schemas with a single root node;
  • The use of hyphens or any other punctuation characters is not allowed in schemas with multiple single root node;

And by the way, can my root node name still contain hyphens or any other punctuation characters?

Yes, it can. In all scenarios as long the root “RootNode TypeName” property doesn’t contain any of them as you will see in the picture below:

BizTalk Schema: Invalid type name error resolved

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Demystify Invalid type name error on BizTalk Schemas (Part I)

Demystify Invalid type name error on BizTalk Schemas (Part I)

A few days ago, while trying to compile a BizTalk Server solution I got the following error: Invalid type name. The root node type has to be a valid C# identifier. I end up solving this problem but while I was preparing this post the reason I realize that the cause and respective solution that I thought to be behind this error was, in fact, incomplete and not accurate.

Most of the documentation available state that:

  • The .Net framework doesn’t allow the “-” within TypeNames because the “-” is reserved.
  • The use of a hyphen (-) in RootNode TypeName is not allowed.

And that statement is incorrect or at least incomplete!

1) What happens if I create a root node with hyphens (-)?

If we create a root node with hyphens, let’s say “My-NAME-SANDRO”, by default the:

  • The “NodeName” property will be set as “My-NAME-SANDRO”;
  • And the “RootName TypeName” property will also be set as “My-NAME-SANDRO”;

And as you can see in the picture below, you will be able to create a schema with a one or more hyphens (-) on the root node name and type name, in fact, they should be the same if you only have one root node in the schema.

BizTalk Schemas: Invalid type name doesn't happen

And again, as you see in the picture you will be able to build and deploy it with success.

But, let’s play a little in order to demystify this Invalid type error that sometimes happens.

2) What happens if we try to change the “RootNode TypeName” property to other value like “MyNAMESANDRO” – without any hyphens (-)?

Nothing will happen, we will still be able to compile and successfully deploy our schema.

BizTalk Schemas: Invalid type name doesn't happen

In fact, this is the best approach.

3) Now, what happens if we try to change the “RootNode TypeName” property to other value like “My-NAMESANDRO” – with hyphens (-)?

Note, that we are changing to a “RootNode TypeName” property to a different value than the “Node Name” but this time including one or more hyphens (-).

If we try to do that we will receive the following error:

Invalid type name. The root node type name has to be a valid C# identifier. It cannot be same as the type name of any other root nodes in this schema

BizTalk Schemas: Invalid type name

Cause

Official Microsoft documentation state that the Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

In fact, it will not allow, any hyphens or other punctuations like “.”, “!” and so on with the exception of the underscore (_)… directly from the BizTalk Editor – we will get that sorted out (properly cleared) later.

Solution

As hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” or “My_NAME-SANDRO” instead of “My-NAMESANDRO” or event “My-NAME_SANDRO”

By removing all hyphens, or any other punctuation characters, from this property in all schemas you will guarantee that you will not face this issue again at least in this project.

4) I change to “MyNAMESANDRO”, what happens if we try to roll back and change the “RootNode TypeName” property again to the original “My-NAME-SANDRO”?

Here’s where the story becomes funny, it will fail!

BizTalk Schemas: Invalid type name

Humm… what? How that’s possible if in point 1 we saw that if the root node name and type name is the same it should work, and it did work before?

Cause

Again, official Microsoft documentation state that the Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

In fact, once you change the name for something else without hyphens or any other punctuation characters, you cannot rollback to the origin (or default) RootName TypeName “My-NAME-SANDRO”.

Solution

The same solution here, as a hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” instead of “My-NAMESANDRO” or event “My-NAME_SANDRO”

However, if you want to rollback to the default RootNode TypeName value, you need to delete the root node and recreate from the scratch, at least directly from the BizTalk Schema Editor.

What is actually the Cause

I think at some point in the past this was a limitation, or maybe a limitation in certain scenarios (we will check this on Part II later on in a different blog) but not really at the moment or in this case: a schema with a single root node.

So, if it worked in the first approach – point 1 – why doesn’t work in the other approaches – point 3 and 4?

Well, in this case, this is just a BizTalk Schema Editor limitation or bug, but let’s call it a limitation.

What is actually the Solution

To solve point 3 and 4 you just need to open the Schema with XML (Text) Editor:

05-BizTalk-Schema-Invalid-type-name-OK

And fix the “rootTypeName” for the value you want: “My-NAMESANDRO” or back to “My-NAME-SANDRO”

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://BizTalk_Server_Project1.Schema1" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://BizTalk_Server_Project1.Schema1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="My-NAME-SANDRO">
    <xs:annotation>
      <xs:appinfo>
        <b:recordInfo rootTypeName="My-NAMESANDRO" />
      </xs:appinfo>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:element name="First-Name" type="xs:string" />
        <xs:element name="Last_Name" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Save it, you now can open it again with BizTalk Schema Editor, compile it and deploy it with any problem.

Keep posted for Part II of this blog post.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Visual Studio: Failed to create window handle for pane while trying to open a Schema

Visual Studio: Failed to create window handle for pane while trying to open a Schema

There are errors that we are familiar with, but I guess this you may never hear about it. I didn’t know it until today: Failed to create window handle for pane ”.

Visual Studio: Failed to create window handle for pane

This happened today while I was trying to open a Schema from my BizTalk Server project. Every other artifact opened well in their designer/editor like Orchestrations, Maps, and Pipelines… with the exception of Schemas.

I try to force it open by the BizTalk Schema Editor by right-clicking on the schema, open with and select the BizTalk Editor (Default) without any result.

Visual Studio: Failed to create window handle for pane open with Editor

I even try to force it open with another editor like XML (Text) Editor – it worked by the way – and once again try to open by the Schema Editor, again, without any practical result.

Note: I had 3 visual studio instances opened with 3 different projects: 2 of them worked well and only one had this problem.

Also, when I try to close this particular Visual Studio instance, I got another error:

Microsoft Visual Studio: Object reference not set to an instance of an object

Microsoft Visual Studio: Object reference not set to an instance of an object

Cause

Honestly, I have no f*** idea… but I know the solution.

Solution

To solve this problem, you need to… do what we normally do when nothing works!

  • Close the Visual Studio and open again

Problem solved!

Because I was unable to close the Visual Studio – Object reference not set to an instance of an object – I terminated the Visual Studio task using the task manager.

Visua Studio: Failed to create window handle for pane End task with Task Manager

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk FILE Adapter Error: File transport does not have read/write privileges for receive location

BizTalk FILE Adapter Error: File transport does not have read/write privileges for receive location

In the spirit of documenting all possible and imaginary errors, let’s address today a classic one: File transport does not have read/write privileges for receive location “DRIVE:FOLDER NAME”.

This happens more than you may think, and today after finish creating a backup port for testing a new process while I was trying to Enable the File receive location I got the following errors:

File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”.

BizTalk Server: File transport does not have read/write privileges for receive location - Error Descriptions

Followed by other similar warning messages:

The Messaging Engine failed to add a receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” to the adapter “FILE”. Reason: “File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”. “.

The receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.

Cause

As I said before this is a classic error, the reason is quite obvious and the error message clearly identifies the origin of the problem.

The problem is that the user that is running the BizTalk Server host instance(s) don’t have read/write privileges in that specific folder.

BizTalk Server: File transport does not have read/write privileges for receive location - User that is running Services

Solution

To solve this problem, you need to give readwrite privileges for the user that is running BizTalk Server Host Instance, in my case “BTSHostSrvc”, into that specific folder. For that you need to:

  • From the file system, access to the folder in question and then right-click on the folder and select the “Properties” option;
  • If attribute “Read-only (only applies to files in folder)” is enabled (selected), disable it (unselect);
  • Then go to the “Security” tab and then click “Edit…” button and then “Add…” button
    • Search for the user that is running the BizTalk Server Host Instance and then click “OK”;
    • For that specific user give read and write access;
      • In my case, because this was/is a “BizTalk process” folder, I gave “Full control”

BizTalk Server: File transport does not have read/write privileges for receive location - Give user Access

  • At the click “OK” and “OK” once again.

Once you give access to the user this classic problem is going away… until the next time!

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk WCF-SQL Error: System.Data.SqlClient.SqlException (0x80131904): Procedure or function ” expects parameter ‘@

BizTalk WCF-SQL Error: System.Data.SqlClient.SqlException (0x80131904): Procedure or function ” expects parameter ‘@

Today while trying to test a solution where it was supposed to invoke a SQL Server Stored Procedure with optional parameters thru the BizTalk Server WCF-SQL adapter I got this following error: Procedure or function expects parameter which was not supplied.

A message sent to adapter “WCF-Custom” on send port “WcfSendPort_SqlAdapterBinding_Procedures_dbo_Custom” with URI “mssql://.// AsyncTransactions?” is suspended.

Error details: System.Data.SqlClient.SqlException (0x80131904): Procedure or function ‘InsertTransaction’ expects parameter ‘@TransactionId’, which was not supplied.

Server stack trace:

at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)

at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)

ClientConnectionId:2731f081-b009-4ba5-a420-95efe7307e71

Error Number:201,State:4,Class:16

MessageId: {746C3B89-A7ED-4C12-8548-0FE174ACA2CB}

InstanceID: {FF06027F-BB96-498B-9515-1E2D55FEAC5A}

BizTalk Server WCF-SQL Adapter: Procedure or function expects parameter

Followed by other similar warning messages:

The adapter failed to transmit message going to send port “WcfSendPort_SqlAdapterBinding_Procedures_dbo_Custom” with URL “mssql://.// AsyncTransactions?”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.Data.SqlClient.SqlException (0x80131904): Procedure or function ‘InsertTransaction’ expects parameter ‘@TransactionId’, which was not supplied.

The adapter failed to transmit message going to send port “WcfSendPort_SqlAdapterBinding_Procedures_dbo_Custom” with URL “mssql://.// AsyncTransactions?”. It will be retransmitted after the retry interval specified for this Send Port. Details:”Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: The start element with name “Request” and namespace “http://BizTalkTesting.SQLBulkOperations” was unexpected. Please ensure that your input XML conforms to the schema for the operation.

BizTalk Server WCF-SQL Adapter: Procedure or function expects parameter - Event Viwer

Cause

The cause of this problem is, once again, quite obvious and the error message present clearly identifies the origin of the problem. The stored procedure is expecting a certain field or several fields that are not being passed maybe because they are marked on the schema as optional fields.

Solution

Of course, the simple problem is to pass all the parameter presented and required by the stored procedure. You should pass them:

  • as NULL, if they are nillable;
  • or as empty strings;

Having said that, my problem was not that quite simple because the parameter described in the error above needs to be optional. After I analyze the stored procedure contract I realized that all of them are set as mandatory fields that need to be passed:

ALTER PROCEDURE [dbo].[InsertTransaction] 
    -- Add the parameters for the stored procedure here
    @SourceSystem  VARCHAR(50),
    @DestinationSystem VARCHAR(50),
    @TransactionId uniqueidentifier,
    @MessageId uniqueidentifier,
    @DocumentType VARCHAR(50),
    @DocumentId VARCHAR(100),
    @BodyMessage ntext,
    @BodyType VARCHAR(5),
    @Priority int
AS
BEGIN
...

When I say that all of them are mandatory, of course, I can set it as NULL but in terms of BizTalk Server, I need to send all the fields in the XML message.

To make it actually optional, we need to change the contract of the schema to something like this:

ALTER PROCEDURE [dbo].[InsertTransaction] 
    -- Add the parameters for the stored procedure here
    @SourceSystem  VARCHAR(50),
    @DestinationSystem VARCHAR(50),
    @TransactionId uniqueidentifier  = null,
    @MessageId uniqueidentifier  = null,
    @DocumentType VARCHAR(50),
    @DocumentId VARCHAR(100),
    @BodyMessage ntext,
    @BodyType VARCHAR(5),
    @Priority int
AS
BEGIN BEGIN
...

Once we modify the stored procedure to have default NULL values the problem will be solved. Now we don’t need to send these fields as NULL or blank, now we actually can omit them from the message – optional fields!

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt)

July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt)

If you follow the BizTalk Server hashtag #msbts on social media like twitter or if you follow BizTalk Server MSDN forum, you will notice one disturbed thread recently: Security Updates released by Microsoft in July 10, 2018 will break you BizTalk Server Administration Console and as a result, you will not be able to access to BizTalk Server “Platform Settings”, getting the following error:

TITLE: BizTalk Server Administration

——————————

Failed to create a BizTalkDBVersion COM component installed with a BizTalk server.

Class not registered (WinMgmt)

——————————

BUTTONS:

OK

——————————

An internal failure occurred for unknown reasons (WinMgmt)

You will not be able for example to: restart the host instances from the BizTalk Server Administration console.

As far as I notice in my clients and in my dev machine, the BizTalk Server engine will still work properly as if nothing happened, it will still be able to receive, process and send all your messages.

Cause

The cause of the problem is still unclear, and Microsoft is still working on how to solve it. And this problem will happen depending in witch SO or BizTalk Server you will have. It has already been registered problems in BizTalk Server 2010, 2013, 2013 R2 and/or BizTalk Server 2016.

What is causing the problem are security updates that were released by Microsoft on July 10, 2018.

Solution

For now, there isn’t a fancy solution, Microsoft is working on a resolution and estimates a solution will be available mid-July.

With that said, the only “solution” or let us call workaround to solve this issue is to uninstall all the “critical” security updates that were installed: in my case, uninstalling the “KB4284833” solved my case.

An internal failure occurred for unknown reasons (WinMgmt) KB4284833

To do that you need to:

  • Press the “Windows key” to open the Start menu and type “Control Panel” and click on “Control Panel” option from the Search window
  • On the “Control Panel” windows, select “Programs” and then “Programs and Features” option.
  • On the “Programs and Features” panel, select “View installed updates” option.

An internal failure occurred for unknown reasons (WinMgmt) uninstall security updates

  • And then you just need to select the update you want to uninstall and then right-click and select “Uninstall”.

In the end, you will need to reboot your machine.

You can always check this forum thread: Microsoft Security Updates cause BizTalk Admin Console errors: An internal failure occurred for unknown reasons (WinMgmt) to check to have an idea what updates you should uninstall depending on your OS version:

  • BizTalk Server 2013 R2: KB4338600 and/or KB4338601
  • BizTalk Server 2010: KB4338602
  • Others: This includes KB4338600, KB4338605, KB4338613, KB4338614, KB4338424, KB4338419

All of them to be checked in your environment and analyzed by your internal teams.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.ConnectionException: Cannot open database “Database-Name” requested by the login. The login failed

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.ConnectionException: Cannot open database “Database-Name” requested by the login. The login failed

To finalize, maybe, these series of Errors and Warnings… Causes and Solutions let’s describe and address a fairly simple one that from time to time appears: Login Failed. While trying to communicate to a SQL Server database to invoke a stored procedure thru BizTalk WCF-SQL adapter I got this following error:

A message sent to adapter “WCF-Custom” on send port “STAGING_SQL_WCF_SEND” with URI “mssql://SQL-SERVER-NAME//AsyncTransactions?InboundId=ins” is suspended.

Error details: Microsoft.ServiceModel.Channels.Common.ConnectionException: Cannot open database “AsyncTransactions” requested by the login. The login failed.

Login failed for user ‘DOMAINBTSHostSrvc’. —> System.Data.SqlClient.SqlException: Cannot open database “AsyncTransactions” requested by the login. The login failed.

Login failed for user ‘DOMAINBTSHostSrvc’.

at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, String accessToken, Boolean applyTransientFaultHandling)

at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)

at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)

at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)

at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)

at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)

at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)

at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry)

at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)

at System.Data.SqlClient.SqlConnection.Open()

at Microsoft.Adapters.Sql.SqlAdapterConnection.OpenConnection()

— End of inner exception stack trace —

Server stack trace:

at Microsoft.Adapters.Sql.SqlAdapterConnection.OpenConnection()

at Microsoft.Adapters.Sql.ASDKConnection.Open(TimeSpan timeout)

at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnection(Guid clientId, TimeSpan timeout)

at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnectionHandler[TConnectionHandler](Guid clientId, TimeSpan timeout, MetadataLookup metadataLookup, String& connectionId)

at Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at Microsoft.BizTalk.Adapter.Wcf.Runtime.OneWayOperationSendPortRequestChannel`1.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open()

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at System.ServiceModel.ICommunicationObject.Open()

at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.GetChannel[TChannel](IBaseMessage bizTalkMessage, ChannelFactory`1& cachedFactory)

at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.SendMessage(IBaseMessage bizTalkMessage)

MessageId: {71CDC883-AE8D-4303-A72E-ADA9ECE91981}

InstanceID: {1EA7B77C-924F-4C74-87DE-BCC4D1AD8E6A}

The cause of the problem is quite obvious and the error message, this time because sometimes is not quite true like we saw in my last post, the error message clearly identifies the origin of the problem.

This problem occurs because the user account that you used to access the database, in my case the BizTalk Host Instance Account, don’t have permissions to connect the database.

Simple problem, simple solution. You need to grant permission to the user to access database

Once again, given “sysadmin” or “db_owner” would solve all our problems but it goes against security best practices and sometimes these tables contain sensitive data or personal data, and nowadays with General Data Protection Regulation (GDPR) in EU this sometimes can be a backdoor for other possible problems and teams need to start taking into considerations these security policies.

You always should give the minimum rights to a certain user for him to do the necessary tasks. Nothing more, nothing less… as things should be.

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[StoredProcedureName] of type StoredProcedure does not exist

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[StoredProcedureName] of type StoredProcedure does not exist

I told you in my last blog post an error never comes alone … when an error appears, it always appears two or three. Or that, or I have a tendency to attract, or find weird errors! This time I was completely stunned: StoredProcedure does not exist, while trying to invoke a stored procedure thru BizTalk WCF-SQL adapter:

Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[InsertTransaction] of type StoredProcedure does not exist

Server stack trace:

at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)

at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)

StoredProcedure does not exist: BizTalk WCF-SQL adapter

or in the event viewer:

A message sent to adapter “WCF-Custom” on send port “STAGING_SQL_WCF_SEND” with URI “mssql://SQL-SERVER-NAME//AsyncTransactions?InboundId=ins” is suspended.

Error details: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[InsertTransaction] of type StoredProcedure does not exist

Server stack trace:

at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)

at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)

at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)

MessageId: {71CDC883-AE8D-4303-A72E-ADA9ECE91981}

InstanceID: {1EA7B77C-924F-4C74-87DE-BCC4D1AD8E6A}

StoredProcedure does not exist: BizTalk WCF-SQL adapter Event Viewer

As I normally say, doubt what you read – even if it is on my blog – because there are many conspiracy theories, and we can find so-called solutions by googling it… but a lot of them are just that: conspiracy theories.

Cause

Personally, I usually like to start with the simplest thing: If it says that doesn’t exist… let’s check, and in this case, the error raised by the adapter it’s just stupid because the stored procedure exists in that specific database as you may see in the picture below:

StoredProcedure does not exist: Stored Procedure exist

At a first glimpse, it seems that was not a security issue because I was able to connect to the database, otherwise, I would get the following error:

Error details: Microsoft.ServiceModel.Channels.Common.ConnectionException: Cannot open database “AsyncTransactions” requested by the login. The login failed.

Again, some conspiracy theories may let you think that:

  • you should regenerate schemas;
  • or that may be a mismatch in the namespaces;
  • the operation is not properly set;
  • that the “?” character that you normally find in the URI is causing this problem;
  • and my favorite is that you should give “sysadmin” rights to the service account that is running the host instance.

Lucky, I remembered to double check the security permission directly on SQL Server, so I opened the SQL Server Management Console with the service account and try to execute the stored procedure and… guest what… I didn’t have permissions!

When I double check the permissions to that service account, it had: db_datareader and db_datawriter… that in some situations are enough:

StoredProcedure does not exist: Service Account Role Permissions

Of course, given “sysadmin” or “db_ower” would solve all my problems but sometimes you are not allowed to do that for security reasons and also is not a best practice, special now with GDPR.

So the problem was clear that the service account that is running the host instance bind to that send port didn’t have the right permissions to execute the stored procedure… unfortunately, the error raised by the adapter is out of context.

Solution

The best approach for you to solve this problem is to create a new server role, for that particular database, in SQL Server:

  • In Object Explorer, access to your database and expand it.
  • Expand the Security folder.
  • Right-click the “Database Roles” folder and select “New Database Role…”
  • In the “New Database Role” window
    • On the “Role name” property, on the General page, enter a name for the new database role, for example, “db_spexecution”
    • On the “Owner” property, inherit from db_datareader and db_datawriter (optional)

StoredProcedure does not exist: Select database User or Role

  • On the Securables page, under Securables, click “Search” button.
    • On “Add Objects” window, select “Specific objects…” and click “OK”

StoredProcedure does not exist: add objects

    • On “Select Objects” windows, click “Object Types…” and then select “Stored Procedures”

StoredProcedure does not exist: Select objects type Stored Procedures

    • After selecting the object type, click “Browse…” and from the “Browser for Objects” windows select the stored procedures you want to invoke. (only the one that you need)

StoredProcedure does not exist: browse objects Stored Procedures

    • Click “Ok” and again “OK” to return to the main “New Database Role” window.
  • The last step, on the Securables page, is to give Execute permissions “Grant” and “Grant with”.

StoredProcedure does not exist: new role securables tab

  • And finally give, on the General tab, add the service account that is running the host instance to the Role Members for that role.

StoredProcedure does not exist: new role General tab

  • Click “OK” to finish.

You can now try to resend the suspended messages or send new ones, and you will be able to communicate and execute the stored procedures without any problem.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

An error never comes alone … When an error appears, it always appears two or three, and I still have thousands to published, but this one but this one made me crazy for a few minutes: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace!

Yes, you read it right, while I was trying to compile a RosettaNet schemas projects, in this particular case a PIP3B2 Advance Shipment Notification I got thousands of errors, 3054 to be exact saying:

Error 1 The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?)

C:TFS…RosettaNet.Common.Schemas.3B2DomainLogisticsCodeListRN_FreightPaymentTerms_01_03.xsd.cs 9 13 RosettaNet.Common.Schemas.3B2 …

Error 3054 The type or namespace name ‘NonSerializedAttribute’ does not exist in the namespace ‘RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?) C:TFS… RosettaNet.Common.Schemas.3B2DomainProcurementINT_Procurement_02_07_01_09.xsd.cs 5072 21 RosettaNet.Common.Schemas.3B2

… and several other schemas as you may see in the picture below.

namespace name 'SerializableAttributeAttribute' does not exist in the namespace

But do not be fooled into thinking this is a problem related exclusively to RosettaNet, it is not, and it can happen with any “normal” or any kind of schemas.

Cause

There are certain keywords, type names, and identifier names that you should use because they are internally used by BizTalk and it way enter in conflict and sometimes originate problems and errors, keywords like activate, atomic, body, task, compensate, method and several ones, you can see the full list here XLANG-s Reserved Words. But there are other keywords that depending on the artifact, may give you problems like:

  • BTS (associated with Microsoft.BizTalk.GlobalPropertySchemas assembly)
  • “-“ in RootNode Typename inside schemas

And “System”!

If you use the keyword “System” inside a schema namespace like:

  • RosettaNet.Common.Schemas._3B2.System
  • “MyNamspace.System.Schemas”

You will not be able to compile your schema project.

The problem, if you download from the GS1 RosettaNet Standards certain PIP’s they will have the following structure:

namespace name 'SerializableAttributeAttribute': RosettaNet PIP3B2 Sctructure

And as you see, there is a folder “System” that inside have several schemas and normally the schema namespace is composed by the project name or (assembly name) and the path to the schema, for example in this case:

  • RosettaNet.Common.Schemas._3B2.System.CodeList
  • Or RosettaNet.Common.Schemas._3B2.System

And this is causing all of these problems because in this case, “System” is a reserved keyword that shouldn’t be used.

Solution

The difficult part of this error was finding the cause of the problem. Once you know what is causing the problem the solution is quite simple. You just need to:

  • Change the “Namespace” property on all the schemas the word “System” to another name, for example, “_System” (to maintain the consistency but it can be other word/value)

In my case, I hade the change the “Namespace” property of the schemas in the “System” folder

namespace name 'SerializableAttributeAttribute': Change schema namespace

You can now rebuild your schema solution and this error should go away.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira