BizTalk 2013 – Unable to import MSI when App uses dynamic ports

Home Page Forums BizTalk 2004 – BizTalk 2010 BizTalk 2013 – Unable to import MSI when App uses dynamic ports

Viewing 1 reply thread
  • Author
    Posts
    • #26353

      New to forum, so firstly hello forum!

      Wonder if any help out there for this odd
      problem.

      Deployment of application msi fails into BizTalk 2013 prod
      environment, fails when deploying the project dll that contains all the
      orchestrations, and reports a failure to apply early bindings.  The only
      early bindings in this project are dynamic send ports.  I cannot recreate
      the problem in in my QAS environment where deployments of the same msi works
      fine.  

      • I can build an msi without any bindings at all except for the
        dynamically created ones, and this also display the same behaviour on import.
         
      • I have test deployed a 2nd unrelated app that also uses dynamic
        send ports, and this displays the problem.  
      • Adding the assembly directly to BizTalk console displays the same
        behaviour.
      • Deployment of msi apps without dynamic send ports are ok.

      The dynamic ports use a pipeline including a custom pipeline
      component which I can confirm is available in the correct directory

      • C:\Program Files (x86)\Microsoft BizTalk Server 2013\Pipeline
        Components

      No specific further detail is available in the error except.

      Import
      Wizard[09/05/2014 08:20:47]: Error in Importing Application

      Import
      Wizard[09/05/2014 08:20:47]: Change requests failed for some resources.

      BizTalkAssemblyResourceManager
      failed to complete end type change request.

      Unable
      to deploy early bindings.

      Failed
      to update binding information.

      Error in the application.

       

      Other information that may be relevant:

      • The main difference between QAS and PROD is that PROD is a two
        node cluster.  Import behaviour is the same if attempted on either
        node.  Assemblies are installed in both
        nodes currently.
      • The dynamic ports are set on handlers that are non-clustered hosts
        (all are for adapter type SMTP).
      • I have ensured that all the adapter handlers are identically setup
        in both environments.
      • The project files were migrated to BizTalk 2013 from BizTalk 2010,
        imported and then converted using VS 2012.
      • The msi has installed the assemblies as per usual and they do
        exist in the .net 4 gac
      • There is a reference to a shared resource in a different application,
        this application is installed and imported ok.

      I’m a bit stuck at what to try now, I
      have option where I could recreate the dynamic ports from scratch in the
      orchestrations and redeploy to dev in the hope it’s something that VS2012
      didn’t handle too gracefully when converting the project.  I could move the functionality into a helper
      class and forget about using dynamic sends, rather not go down that route.

      Since writing this up, I have removed dyn ports from one app, and successfully deployed – that not an approach I want to follow but it will get me around a few pressing deadlines.  I have also created a test app in VS 2012 and included a dyn smtp send, and this also displays the problem so I’m confident it is not a obvious migration problem between VS2010 & VS2012.  Having reviewed the adapter handlers I can’t see any difference between prod and qa in terms of which hosts instances are configured to receive/send for each.

       Any comments and ideas for further investigation are most welcome.

    • #26357

      Just try restarting the SSO service on both of the prod node and try again

      • #26440

        That didn't sort it but thanks for the input.

        For any other casual readers, i did get to the bottom of it and it was SQL permissions missing from the default roles needed to access the new tables in support of the changes to dynamic port functionality.  I believe this is resolved in a CU1 although I had the DBA make the permission changes before I found this official fix.

        support.microsoft.com/…/2838133

        I'm doing some testing on a new sandbox this week, and will come back and confirm if the cu1 also sorts out the permissions.

        the differences in behavior I experienced were to do with elevated permissions remaining on my SQL access in the UAT.  That confused matters, but once that was understood it was fairly straightforward to find the problems.

Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.