Q & A : BizTalk Server 2010 Configuration Error SSODB Cannot be created, SSODB is not accessible

Q: I have encountered the following error during BizTalk 2010 Configuration Error's : SSODB Cannot be created, SSODB is Not Accessible, SSODB is Used by Another service etc..,

Ans: 

There are a few known issues encountered during installation and configuration of BizTalk Server 2010,  There are a few points that you need to verify before you start configuring BizTalk Server 2010

1. MSDTC Should be configured and Tested for ping using DTC Tester, DTC Ping for Multi-server Installation.
2. Installing User need to have permissions to update Active Directory for If Domain Accounts are used for BizTalk Configuration
3. BizTalk Service Account used for configuration needs  to have sufficient permissions to access database It needs to be part of SSO Administrators group during configuration
4. You need to provide full SQL server name during installation SERVER_NAME\INSTANCE_NAME (Do NOT provide SQL Server Alias even if you have created one it may cause problems).
5. In case you have installed .Net 4.0 as a part of Visual Studio or something else you need to register SSOSQL.dll so that SSO is registered to point the correct version of .Net Framework and load the correct dll. REGASM the SSOSQL.dll

This must be performed in order to allow the BizTalk Server Configuration console to access the database when performing the Enterprise Single Sign-On initial group creation.

1. 1.     On servers which have .NET 4.x installed, a hotfix to repair the .NET version control on the SSOSQL.dll must first be run.  As an administrative user on the BizTalk Server, access this hotfix:
   
   http://www.microsoft.com/en-us/download/details.aspx?id=12284
   2.     As an administrative user on the BizTalk Server or using the Command Prompt being run as an Administrator, register the SSOSQL.dll using:
   
   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe “C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll”
   3.     Ensure you are registering the SSOSQL.dll using the .NET 4.x version of RegAsm.exe or you’ll be wasting your time!  You can register it with an earlier .NET version RegAsm.exe but it will not work – it will not allow your BizTalk Server Configuration to access the database to setup the SSO Group.

Read more ...

Q & A: How To: Get rid of wcf one way port communication error

Q:

Hi,

 I Consumed one wcf one way serive at send port,but it is throwing error asking for reply.

A message sent to adapter "WCF-WSHttp" on send port "WcfCacheService" with URI "" is suspended.

Error details: System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

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: {BE03C2AD-5888-42AA-AE1B-D25965C6446A}

 Thanks,

Sol:

Hi,

Problem got solved finally....feel gr8..

In Binding tab of WCF-Custom adaptor...Binding Type is customBinding

in the bindings rightclick on CustomBindingElement->Add Extention->select one way->and move this to up other wise will get error,bcoz http transport should be last.

click ok and apply..thats it..

Regards,

Read more ...

Biz Talk Q&A : Register Correct version of ASP.NET in IIS

Q:

Getting the below error while browsing the website running on ASP.NET 4 application pool.

Server Error in '/myVDir' Application. 

-------------------------------------------------------------------------------- Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.TypeLoadException: Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

1. Re-register the .NET 4 framework of ASP.NET with IIS

1. Force this module to be loaded only inside a 2.0 application pool by changing the configuration manually

1. Remove this 2.0 version Module from the list of modules if you are planning to run only ASP.NET 4 application pools.

You will run into this problem only if you install the .NET 3.5.1 WCF HTTP Activation feature after the installation of .NET 4 framework on your server.

Cause

Installation of .NET 3.5.1 WCF HTTP activation feature adds a global module for the 3.0 framework’s 'System.ServiceModel’ assembly for the type 'System.ServiceModel.Activation.HttpModule'. Since the application pool’s runtime version is v4.0, this assembly is tried to be loaded from the .NET 4 assemblies folder. Since, the definition of the 'System.ServiceModel.Activation.HttpModule’ is now moved to the “System.ServiceModel.Activation” assembly, it fails.

This problem doesn’t occur if you run your application pool under classic mode. You can resolve the problem by following any of the following:

Answer #1

To re-register the ASP.NET 4 assemblies with IIS, open a command prompt (as an admin), and navigate to the .NET 4 framework folder (%windir%\Microsoft.NET\Framework\v4.0.30319). Type aspnet_regiis -iru, and press enter. This command will re-register the ASP.NET 4 framework with IIS which will modify the ‘ServiceModel’ configuration to be loaded only inside a .NET 2.0 application pools. For some reason, you choose not to re-register the ASP.NET 4 version assemblies with IIS, you can follow the resolution #2 explained below, which will do the same configuration change, but manually.

Answer #2

The worker process tries to load the assembly since it passes the pre-condition. Its pre-condition is just “managedHandler” which doesn’t specify the runtimeVersion information. By default it is loaded inside the application pools running with any version of .NET framework.

To resolve the problem, change the configuration of the module to be loaded only if the runtime version is 2.0, so that it doesn't interfere with .NET framework 4 application pool:

<add name="ServiceModel" type="System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler,runtimeVersionv2.0" />

AppCmd syntax:

appcmd.exe set config -section:system.webServer/modules /[name='ServiceModel'].preCondition:"managedHandler,runtimeVersionv2.0" /commit:apphost

Answer #3

Alternatively, you can uninstall the .NET 3.5.1 WCF HTTP activation if you are not planning to use this feature. This would simply remove the module ‘ServiceModel’ from the list of modules. Remember, this is going to affect all the application pools, so if you have any application pool which might use this module, then do not proceed with the uninstallation. Alternatively, you can remove it from the global modules list, and add it specifically to the application needing it.

You can also simply remove the module from the modules list. Below is the appcmd to remove the module from the global list.

AppCmd to remove the module:

appcmd.exe set config -section:system.webServer/modules /-"[name='ServiceModel']" /commit:apphost

Below is the AppCmd to add the module to the application needing it.

appcmd.exe set config "Default Web Site" -section:system.webServer/modules /+"[name='ServiceModel',type='System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089',preCondition='managedHandler,runtimeVersionv2.0']"

Read more ...

BizTalk : How To : Trouble Shoot BAM EventBus Service Error in Event Log

post by Tiho

Here are 8 tables in each BizTalk Message Box database which store the tracking data before it is imported by the BAM EventBus Service (a.k.a. TDDS or Tracking Data Decoding Service) into the DTA/HAT and the BAM Primary Import databases. The tables are named TrackingData_x_y where 0 ≤ x ≤ 1 and 0 ≤ y ≤ 3. It is absolutely critical that the sizes of these tables do not increase over time. If the sizes are increasing than either TDDS is not able to catch up with the load or it is not working properly. There is a performance counter that can be used to monitor the size of the tracking data – BizTalk:Messsage Box:General Counters\Tracking Data Size.

The first step to troubleshoot issues with the tracking data is to examine the Windows Event Log on the BizTalk Tracking Host machine for errors from the BAM EventBus Service. Error information along with the serialized original tracking data might be available in the TDDS_FailedTrackingData tables in the DTA/HAT and the BAM Primary Import databases. Another place where error information might be available is the TDDS_Heartbeats table in the BizTalk Management database.

In this post I will focus on one very common cause which manifests as an error from the BAM EventBus Service in the Windows Event Log with event ID 25. 

The error should look like this:

Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 25
Date: 12/20/2006
Time: 10:38:27 AM
User: N/A
Computer: TRACKINGHOST
Description:

Either another TDDS is processing the same data or there is an orphaned 
session in SQL server holding TDDS lock.Timeout expired. The timeout 
period elapsed prior to completion of the operation or the server is not 
responding. SQLServer: DBSERVER, Database: BAMPrimaryImport.

This error will usually show up every 5 minutes or so. Below are the steps to resolve it.

First, make sure that you are not hitting any of the issues described in this article. If this is the case, then killing the orphaned sessions or restarting the SQL Server machine will resolve the issue. You can use the information in this article to identify orphaned sessions.

If the issue is still there, then you most certainly have permissions problems. The account under which TDDS (and the BizTalk Tracking Host) is running must have execute permissions for the following stored procedures in the BizTalk Message Box database: TDDS_RedisterTDDSAccess and TDDS_GetNumTrackingPartitions. The same account must also have execute permissions for the TDDS_Lock stored procedure in the DTA/HAT and the BAM Primary Import databases.

The permissions are set correctly when BizTalk Server is first installed but might be altered later directly or indirectly by manually setting explicit deny permissions for the specific account or any group that it is a member of.

The best way to check that permissions are indeed the problem is to open Task Manager on the Tracking Host machine and on the Processes tab check the account under which the BTSNTSvc.exe process is running. This is the Tracking Host account. Now start SQL Query Analyzer or SQL Management Studio (or any of the command line counterparts) with the same user credentials as BTSNTSvc.exe. You can use the “runas” command or right-click on a shortcut and choose “Run as…”. I suggest that you do this test on the Tracking Host machine to rule out any network connectivity issues.

After you have connected to the correct SQL database execute the following:

In all BizTalk Message Box databases:

DECLARE @RC int
DECLARE @retVal int
EXEC @RC = [BizTalkMsgBoxDb].[dbo].[TDDS_RegisterTDDSAccess] @retVal OUTPUT 
SELECT @RC
GO

DECLARE @RC int
DECLARE @nPartitions tinyint
EXEC @RC = [BizTalkMsgBoxDb].[dbo].[TDDS_GetNumTrackingPartitions] @nPartitions OUTPUT 
SELECT @RC
GO

In the BizTalk DTA and BAM Primary Import databases:

DECLARE @RC int
DECLARE @resource nvarchar(128)
DECLARE @milisecTimeout int
DECLARE @retVal int
SELECT @resource = N'Foo'
SELECT @milisecTimeout = 5000
EXEC @RC = [BAMPrimaryImport].[dbo].[TDDS_Lock] @resource, @milisecTimeout, @retVal OUTPUT 
SELECT @retVal
SELECT @RC
GO

The results of these queries should be 0 and there should not be any errors. If you get “EXECUTE permission denied” errors then grant the corresponding execute permissions until you can execute the queries without any errors. At this point TDDS should start moving the tracking data from the Message Box databases to the DTA and the BAM databases.

Read more ...

BizTalk : How To : Rename BizTalk Server Machine Walkthrough

Renaming your BizTalk machine

post by Saravana Kumar

Anyone who been working on BizTalk server long enough will know renaming a BizTalk machine is not a trivial task. It always involves quite a bit of manual work, things like

• Un-configure the existing setting either using the UI or ConfigFramework /U switch
• Deleting the Databases manually,
• Re-Configuring it, which will raise tons of errors.

It's never been a smooth procedure. Recently I had to go through this painful process, because due to corporate policy changes, they renamed all of our developer workstations.
Here I'll explain how we utilized the Disaster Recovery scripts available as part of BizTalk installation to help us rename the BizTalk machines smoothly (mainly without the pain of un-configure and re-configure). If everything goes smoothly you should be done in less than 10 minutes.

Disclaimer: Do this at your own risk, it worked for me.
Edit SampleUpdateInfo.xml file:

• Navigate to the following folder C:Program FilesMicrosoft BizTalk Server 2006SchemaRestore and open the file SampleUpdateInfo.xml file in your favourite editor.
• Find and Replace all the "SourceServer" value with your original Server name
• Find and Replace all the "DestinationServer" value with your new Server name.
• Stuff related to Analysis, BAM, RuleEngine, HWS, and EDI are commented by default, if you are using them in your environment un-comment the required ones.
• Save and Close the file.

Run the scripts to update database and registry:

Run the following command in the command prompt
cscript UpdateDatabase.vbs SampleUpdateInfo.xml

This script will update all the BizTalk databases with the correct server name. You need to run this script only once in a multi BizTalk server environment.
Run the following command in the command prompt

cscript UpdateRegistry.vbs SampleUpdateInfo.xml

This script will update the local registry with the correct server name. You need to run this script on each BizTalk server you have in the group.

Restart WMI Service:
Open the Service control manager (services.msc) and restart the "Windows Management Instrumentation" service. This step is required because most of the administration tasks you perform from the admin console depends on WMI.

Promote the new server as master secret server:
Follow the steps outlined in this link http://msdn.microsoft.com/en-us/library/aa559842.aspx to promote your new server as master secret server.

Configuring the BizTalk Administration Console:
Open the BizTalk administration console, click on the existing node (the one pointing to original server), right-click and remove.
Right click on the "BizTalk Server 2006 Administration" node and select "Connect to Existing Group…". Provide the new Server Name and select the BizTalkMgmtDb database.
Click Ok.

Update your Visual Studio project properties to point to new Server:
Most of your Visual Studio BizTalk projects will be still pointing to the old management db server. Trying to deploy your project will result in an error message like this "Login failed for the user ''. The user is not associated with a trusted SQL Server connection. "

Couple of Caveats:
At this point you should be able to see a working BizTalk Group. I experienced couple of problems,
1. When your try to expand the "Platform SettingsAdapters" and select any adapter from the list, you'll see an error message like this "Unable to load adapter handler for XXXX adapter. (Microsoft.BizTalk.Administration.SnapIn) Access Denied (System.Management)"



The machine name in the error message is pointing to my old server name. I wrote a small console application utilizing the BizTalk WMI classes and they all worked fine. It shows clearly the wrong server name is stored somewhere and the admin console is trying to connect to the old server. BTW there won't be anything in the event viewer to assist you
I opened the SQL Management studio and made the following changes in the BizTalk Management Database (BizTalkMgmtDb)
1. adm_group table, SSOServerName Column: This one had the original server name, I entered the new server name
2. adm_server table, Name column: Again this one had the original server name, I entered the new server name.
Restart all the BizTalk/SSO services.

NOTE: These procedures were performed on a Windows XP workstation (single BizTalk installation), SQL Server installed on the local machine. No named SQL instance. The procedure should work for Windows 2003 on a remote SQL Server with multiple BizTalk servers. I'm not sure about the SQL Named instance setup(example people using SQL Express, where the instance name will be for example ServerNameEXPRESS).

Read more ...