I've have created in BizTalk 2009 a wcf-netmsmq receive location. The MSMQ queue is also created as a private queueand the BizTalk service account has full access to the private queue.

Via the BizTalk WCF Service Publishing Wizard I created a meta data only endpoint. Based on my WCF-NetMsmq receive location and added the schemas by hand.
The webservice is created. The application pool the webservice uses is runs under the identity with the service account voor BizTalk. (So it has access to the BizTalk DBs)

When I want to see the WSDL i get the exception: Root element is missing.

I also tried to look into what's happening in the service factory and it seems that the additional properties are empty based on the the fact that a document is empty it comes with the exception root element is missing.

Please help.

Is the private queue on the same box as BizTalk?

The port binding details do have to match a few other queue details. Did you create the queue as transactional? If so, specify this in the port binding options.

Thanks,

Hi,

I also got the "Root element missing" problem while exposing schema as metadata only endpoint using BizTAlk WCF service publishing wizard. I was using WCF-WSHttp. I am still perplexed.

Hi,

The private queue runs on the same box as BizTalk.
And yes the queue is transactional as wel as the receive location. I know that the port will be disabled if there's mismatch between the configurations.

similar thread http://social.msdn.microsoft.com/Forums/en/biztalkr2adapters/thread/4573b7fc-fc6f-4353-b51e-2db90a4cd610

Raja's thread suggested specifying an account for the app pool identity with access to the BizTalk databases, but it sounds like you did this.

When working with netMSMQ I found this walkthrough guide helpful: http://msdn.microsoft.com/en-us/library/bb259950(BTS.20).aspx

It mentions some steps for configuring the deployed service after going through the wizard under "To configure the Web application hosting the published metadata service". Make sure you follow these steps too.

Thanks,

@Raja: Anonymous access is enabled.

@Ben Cline:
I followed that walkthrough as well. The only difference was that the flag trust="full" should also be added. Which I did. And still the same exception.

Hi,

I think this is a bug with BizTalk WCF Service Publishing wizard. When I publish using service endpoint everything is fine. Also while using BizTalk WCF Service Consuming Wizard if I choose MEX endpoint everything is still fine. I am totally flummoxed. Microsoft might clear the dilemma.

Unfortunately the "root element missing" error is such a general one and is in fact a red herring too (the root issue is something different) that this is annoying.

Could you show the stack trace? Sometimes this is helpful for identifying where the underlying issue is.

Thanks,

Try turning Windows Authentication off on the site and then going back to the MSMQ
receive location and toggling the security bindings from None to Windows and
back again. This and the step below worked me.

Try using a highly privileged user to run the app pool. I also " changed the
site to run under an AppPool that has permissions on
BizTalk." but this did not work.

I think that publishing a BizTalk schema as a netMsmq service is flakey. I found
that same service could be browsed 'back in the office' but when I was on the
customers site I could not browse to it. I think that it is due to some funny
policy that the customer is running but I could not get the the bottom of it. I
enlisted the help of two BizTalk MVP's on this one and above is the best they
could come up with.

Please let the group know if u find out what the real problem is?

Hi,

You can see my reply in the following post:
http://social.msdn.microsoft.com/Forums/en-US/biztalkr2adapters/thread/2bfcc374-22b3-43f6-97bf-3f444b804456

Hi Every one:

I am facing the exact same issue. I see this thread is kinda sleeping for a while and was wondering did anyone find any solution?

Did you have a stack trace you could show? This thread was basically waiting on one. I would get one from the error on screen or from an event log message.

Thanks,

Hi Ben:

Below is the stack trace. I sorry it took me a bit longer to get you the stack trace because surprisingly when I tried creating a new service (with the net.msmq adapter receive port) and it worked fine. After a restart, it stopped working again I got the infamous "root element missing..." error.

 

Server Error in '/BizTalkWcfService' Application

That's pretty weird that it stopped working after the restart. The stack trace in this case does not help much.

For MSMQ I would just make sure the permissions are correct on the queue - the host account you are running under needs permission to the queue (it may need full control).

Thanks,

I still have not found a good solution for this but the same question came up on the Australian newsgroup in December too(I show that thread here for those that can't get to it). Everyone threw their hands in the air in that forum too.

I wish someone could work out how to solve this one. May be this thread would be clearer if it said something like "Problems publishing a BizTalk schema as a netMsmq service " because the title of this thread is not specific to this problem.

Re: [oztalk] Re: publishing a BizTalk schema as a netMsmq service

 

Yeah Greg and I looked at this quite extensively the other day and found nothing. i am convinced this is either a) some obscure undocumented requirement or b) a bug! how do we go about logging a support call with MS on this one?

2009/12/17 marktbrimble <mbrimble@...>

 

Try turning Windows Authentication on the site and then going back to the MSMQ receive location and toggling the security bindings from None to Windows and back again. This and the step below worked me.

Try using a highly privileged user to run the app pool. I also " changed the site to run under an AppPool that has permissions on
BizTalk." but this did not work.

I think that publishing a BizTalk schema as a netMsmq service is flakey. I found that same service could be browsed 'back in the office' but when I was on the customers site I could not browse to it. I think that it is due to some funny policy that the customer is running but I could not get the the bottom of it. I enlisted the help of two BizTalk MVP's on this one and above is the best they could come up with.

Please let the group know if u find out what the real problem is?

--- In oztalk@..., Ryan CrawCour <ryancrawcour@...> wrote:
>
> and that was?
>
> 2009/12/15 marktbrimble <mbrimble@...>
>
> >
> >
> > Snap I asked the same question on this newsgroup a couple of weeks back.
> > I eventually worked out a pretty unsatisfactory solution;
> >
> > --- In oztalk@... <oztalk%40yahoogroups.com.au>,
> > "marktbrimble" <mbrimble@> wrote:
> > >
> > > I thought I should report back about some limited success. I managed to
> > browse to the page after the following actions;
> > > 1. unticking Windows Authentication and leaving only anonymous on
> > > 2. putting my user in the app pool and not the Biztalk host user.
> > > 3. On the MSMQ receive location toggling the security from None to
> > windows and then back again.
> > >
> > > This worked on one development server but not the other two. So I am not
> > sure which step solved the problem. After three sleepless nights I'll buy
> > this one. At least now the other developers can browse to the metadata. The
> > next step is for them to use the WCF-netMSMQ receive location.
> > >
> > > Thanks to Thiago for suggesting these actions.
> > >
> > > P.S. the other developers seem to be sending stuff to the WCF-netMSMQ
> > port now so it looks like everything is OK now but I'll check that on Monday
> > now.
> > > Time to go and watch the Rugby and forget about work.
> >
> > >
> > >
> >
> > --- In oztalk@... <oztalk%40yahoogroups.com.au>, Ryan
> > CrawCour <ryancrawcour@> wrote:
> > >
> > > Hi
> > >
> > > I have a one-way receive location set to Wcf-Custom with bindings for
> > > NetMsmq pointing at a local queue.
> > > I then used the Publishing Wizard to publish the "Metadata only
> > endpoint",
> > > which went ahead and created the site.
> > > I changed the site to run under an AppPool that has permissions on
> > BizTalk.
> > > When I try browse to the svc file i keep getting a "Root element is
> > missing"
> > > exception.
> > >
> > > Stack Trace seems to point to
> > >
> > Microsoft.BizTalk.Adapter.Wcf.Metadata.ReceiveLocationProxy.ExtractProperties(String
> > > customCfg) +129
> > > which seems to be that it cannot extract the properties of the Receive
> > > location correctly.
> > >
> > > I'm going nuts with this .... Any ideas?
> > >
> > > Thanks
> > > Ryan
> > >
> >
> >
> >
>

All,

I was able to get past this at a client location. We were using the following walkthrough: http://msdn.microsoft.com/en-us/library/bb259950(BTS.20).aspx.

The extra steps included here seemed to help such as setting the trust level to full in the web.config and making sure the WCF Transport settings match the type of queue created (transactional vs non transactional, etc).

Thanks,

I was seeing the same error, same stack trace as an earlier reply. I was following the walkthrough and had done the extra steps of setting the trust level to full and making sure the WCF Transport settings matched the type of queue. I found that for each attempt to browse the metadata, I had a series of ENTSSO events in my Event Log. The events reported access denied and that "the client must be a member of one of the following accounts to perform this function", with the accounts/groups being SSO Administrators, SSO Affiliate Administrators, or BizTalk Server Administrators. The account it reported as needing this access was MyDomain\MyServer$. The app pool identity for the service publishing the metadata started off as the default Network Service. I changed it to LocalSystem and that didn't seem to change the error or the account identified in the ENTSSO event. Maybe I missed some reset somewhere to make my change really take effect.

But when I change the app pool identity to an account that a) has all the access it needs to the BizTalk database and b) is a member of SSO Administrators, the error went away and the service is publishing the metadata just fine. This is somewhat consistent with an earlier response that recommended changing the app pool identity to a "highly privileged user".

Hope this might help someone else.

Zoe

I too was seeing the same error after following the walkthrough. I thought I had given the app pool account all the permissions it needed to access the BizTalk databases, given the app pool account was running under my BizTalk service account. However, in my case, this wasn't enough.

According to the the note under Step 1 in 'To configure the Web application for publishing service metadata' section at http://msdn.microsoft.com/en-us/library/bb743780(BTS.10).aspx, the app pool account (W2K3, W2K8) / ASPNET account (XP) should also be placed in the BizTalk Server Administrators group. I followed this advice, and sure enough, my MEX service came good.

Cheers

Daniel

If nothing helps, I'd suggest to create a .NET helper class to communicate with MSMQ queue.

Then use this class from the Expression shape.

It should not be difficult task.

You lost the port features like replay, but maybe you don't need them.

I encountered the same error message "Root element is missing" when exposing only the Metadata of a BizTalk 2010 receive location with the NetTcp binding.

The AppPool worked fine for services over BasicHttp.

To make it work for NetTcp binding I indeed added the bts service account to the BizTalk Administrators Group. Next I was able to browse my service

regards,

Mark Willems

It's resolve on mine, by checking all configuration, i found i didn't created outbound map (i was using same map as Pipeline map), Added map in outbound map, It's started working.

To test what you getting in sending file, set as FILE adapter and you will knw what you are missing.

It's work for me.