August 2009 - Posts

BizTalk Server 2009 Installation Errors
20 August 09 09:29 PM | Johan Hedberg | 2 comment(s)

I just thought I’d mention these install errors since I’ve gotten them now on several occasion when installing BizTalk Server 2009 Enterprise 64-bit Single Sign On Master Secret Server on Windows Server 2008 and SQL Server 2008 (although I doubt the last one has any role in these errors).

This page describes the procedure of Installing and Clustering the Enterprise SSO Master Secret Server, although it mentions nothing about these specific peculiarities.

Error1

Log

[10:03:05 Error] Setup runtime files for AMD64 platform: Fatal error during installation.
[10:03:05 Info] Marking Stage: Install/Installing components as Completed in TaskInfo XML
[10:03:05 Info] ReadTaskInfoXML: Attempting to load TaskInfo xml from string
[10:03:15 Info] Showing MessageBox with text: The following platform components failed to install and will need to be manually installed before setup can proceed: Setup runtime files for AMD64 platform: Fatal error during installation. Check the log for details. Return Code: 1

MSI (s) (8C:FC) [10:03:04:688]: Product: Microsoft BizTalk Server Setup Bootstrap Files (x64) -- Error 1310. Error writing to file: atl90.dll. System error 0. Verify that you have access to that directory.
Error 1310. Error writing to file: atl90.dll. System error 0. Verify that you have access to that directory.
Action ended 10:03:04: InstallFinalize. Return value 3.
Action ended 10:03:05: INSTALL. Return value 3.
MSI (s) (8C:FC) [10:03:05:867]: Product: Microsoft BizTalk Server Setup Bootstrap Files (x64) -- Installation failed.
MSI (s) (8C:FC) [10:03:05:868]: Windows Installer installed the product. Product Name: Microsoft BizTalk Server Setup Bootstrap Files (x64). Product Version: 3.8.368.0. Product Language: 1033. Installation success or error status: 1603.

Resolution

I have received this error if I connected to the server using Remote Desktop/Microsoft Terminal Service Client without using the /admin flag (former /console flag). Read more here.

Error2

Log

[10:34:48 Info] Showing MessageBox with text: The following platform components failed to install and will need to be manually installed before setup can proceed: Enterprise Single Sign-On Server: Unspecified error Check the log for details. Return Code: 1

[10:34:35 Info] Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information.
[10:34:35 Info] Showing MessageBox with text: Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information. Return Code: 0
[10:34:35 Info] Action 10:34:35: Rollback. Rolling back action:
[10:34:39 Info] Detailed Log information for product D:\Install\Biztalk 2009\Platform\SSO64\SSO64.msi is available at <a href="C:\Users\xxx\AppData\Local\Setup(072909 103411).log">DetailedLog</a>
[10:34:39 Info] MSI installation returned 1603 - Fatal error during installation.
[10:34:39 Error] Error 1928 occurred during MSI installation.
[10:34:39 Error] Action 10:34:30: InstallComplus.8E665C9D_5561_45FC_AAA0_3878B87F3B86. Installing COM+ components
[10:34:39 Error] Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information.
[10:34:39 Error] c:\depotsetupv2\private\common\setup\wizard\exe\setup.cpp(1670): FAILED hr = 80004005

Resolution

This error has occurred in clustered environments when the clustered instance of MSDTC was not active on the node on which the installation was taking place. Failover the MSDTC to the current node that installation is to be run on and try again.

Captcha updated – Email re-enabled
15 August 09 07:26 PM | Johan Hedberg

Just a short note and apology to those that have used the contact form in the last few weeks. While we have been working to find a suitable method to stop spam we have disabled the email functionality altogether – which has affected the contact form as well. Messages sent through the contact form over the last couple of weeks may therefore not have reached us. Since enabling a new captcha, reCAPTCHA, spam has stopped and the email functionality is once again enabled. I can highly recommend it. If you feel you have not received a response to your message, please accept our apology and feel free to try again.

Filed under: ,
Redeploying a schema assembly…
15 August 09 05:01 PM | Johan Hedberg

If I ask you upfront: Can I redeploy an assembly to BizTalk (that contains a schema) that is referenced by (and used in) another assembly? – What would you say?

Some of you might say yes, some might say no. And you’d both be right! It all depends on what it is being used by and how it’s deployed.

Redeploying a schema referenced by a map in another assembly

Yes. This will work – provided you specify overwrite when redeploying or updating the resource, and regardless if the resources are placed in the same or different applications. The behavior is the same in all relevant tools, whether it is Visual Studio, BizTalk Administration Console or the BtsTask tool. For the remainder of the discussion I’ll use BtsTask only, since it has the easiest (or at least most verbose) output to follow.

Sidenote: If you don’t specify overwrite, you’ll get something like:
Error: Failed to add resource(s).
Resource (-Type="System.BizTalk:BizTalkAssembly" -Luid="SchemaProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0a220f093608cb3f") already in store.
1) Use BTSTask's overwrite flag or
2) Set redeploy flag to true in BizTalk Project or
3) Click overwrite all checkbox in Admin MMC to update if the resource exists in the specified target application "SchemaApplication".
Overwrite flag will be ignored if the resource is associated with another application.

Redeploying a schema referenced by an orchestration in another assembly in the same application

Yes. This will work. It assumes that the orchestration is unenlisted (which may be a huge problem in some cases), or you will get an error. If it is however, and as long as you specify the overwrite flag, BtsTask will happily inform you of it’s progress telling you exactly what it’s doing – which is to find the referencing resources, save their binding information, removing them, then doing the same with the thing you want to redeploy, then deploying the thing you are deploying and applying it’s bindings, and finally deploying the referencing resources and applying their tucked away bindings.

The tools does all this for you, in a controlled manner under one transaction that can be rolled back if something fails. BtsTask output is here.

Redeploying a schema referenced by an orchestration in another assembly in another application

No. This is where the fun stops. You cannot do this with the out of the box tools. The Application boundary will stop you. To be frank: WTF!? For someone approaching BizTalk Server 2006/R2/2009 from a 2004 (single/no application) perspective this could invalidate their whole deployment strategy. BtsTask output is here.

In Summary

Why is this happening? If we use Reflector to disassemble BtsTask and the Deployment API’s it uses it’s apparent that the whole things is built around an Application and it’s around an Application that everything revolves. So… If you are faced with this kind of requirement for your deployment scenarios - the tools won’t do it for you - you have to do it yourself. Mimicking the steps taken by BtsTask, but without the dependency on Application, is my recommended approach. But the implementation of that is for another post…

Has anyone already done this and have or know of a tool developed for this purpose?

Update: The odd cases

I want to add that I make no claim to cover all scenarios in the above write up. I only wanted to highlight the Application boundary as one of the things that will have a big impact on redeploying schemas. We have for example come across scenarios such as when an orchestration within the same application is "specify later"-bound to a port, on which there are maps, for which there are no referential relationship with the orchestration assembly, though there are with the schema assembly being redeployed. This scenario may fail, depending on your luck, where BizTalk is unaware of the correct order to re-deploy these things. This may result in the orchestration (and the port) being re-added before the assembly containing the maps is in place. Which in itself will fail since an attempt to add a binding containing a port that has maps configured that are not deployed will of course not work. There are more scenarios, and it would be unfair to expect any tool to cover them all.

This Blog

News

    Messenger

    Twitter Updates

      Follow me on twitter

      Visitors

      Feedburner Subscribers

      Locations of visitors to this page

      Disclaimer

      All material is provided AS IS voiding any thinkable or unthinkable effect it might have for any use whatsoever. There... is that clear enough ;)

      Pages

    Syndication