Pages

Showing posts with label SSO. Show all posts
Showing posts with label SSO. Show all posts

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

Tuesday, July 29, 2014
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 ...

Advanced Users Biztalk WIKI : Useful How to Links Part - 5

Tuesday, June 12, 2012
 Useful How to Links Part - 5

Bre Static Support Key

Calling Data Access from Ado.Net

Sso Configuration Storing Values

Xml Document XPath Sample

ESB Dynamic Routing using Itineraries


Read more ...

BizTalk SSO Error – 0xC0002A04, The application does not exist

Monday, October 17, 2011
post by Zeshawn
While deploying my applicaiton into a locked out enviornment (DR), I ran into an SSO problem (as initially thought).  We were using Microsoft’s Application Configuration utility to manage key value in the SSO.
As part of our deployment, we ran into the following problem – with a warning in the event viewer:
======
 SSO – Error creating the application
 Event Type: Warning
Event Source: ENTSSO
Event Category: Enterprise Single Sign-On
Event ID: 10536
Description:
SSO AUDIT
Function: GetConfigInfo (ConfigProperties)
Tracking ID: 764c4b7c-4164-434c-b023-0f8c1f6213bf
Error Code: 0xC0002A04, The application does not exist.
======
As I initially thought this to be an SSO problem, the reality was that our “locked-out” enviornment was pointing to the incorrect SSO database !!
In the Enterprise SSO Admin application, it was connecting to the production  SSO database, not to the actual one (DR). Everything else was point to the DR SSO database. This must be a carry over from when we have the BizTalk environment’s linked for transaction logging. When we reconfigiured SSO to point to it’s own database the SSO Admin tool kept pointing to Production.
Solution: Right click on the root node in the SSO Admin and select the correct SSO Server name.
Problem solved :)
An interesting question would be : How does the SSO Application Configuration tool determine which SSO database to connect to ?
Read more ...

Altering and Restoring Biztalk Databases | Master Secret , Restore , BiztalkMgmt

Monday, September 26, 2011
Q:
We restored the BizTalk production databases of BizTalk 2006 R2 to a new (for various reasons) test environment. We made changes in BizTakMgmt  tables and BAMPrimaryImport tables, more or less followed the http://msdn.microsoft.com/en-us/library/aa561125(v=BTS.20).aspx and http://msdn.microsoft.com/en-us/library/ee267635(v=BTS.10).aspx
But got into following two issues
1. It is showing in the event viewer that this test computer is receiving secret from production server's SSO, rather than test compter.
There is ESSO service running on the test computer. Both production server and test server environments use the same domain id.
How do   I make it to point to test ESSO it self ?

Event viewer entries

 Got the previous secret from the master secret server.
 Secret Server Name: ProdBizTakServer
 MSID: 8f26122c-4830-4216-bba5-e49dca3ba13b
 Got the current secret from the master secret server.
 Secret Server Name: ProdBizTakServer
 MSID: 8f26122c-4830-4216-bba5-e49dca3ba13b
2. HAT's Preferences,Tools, Live Data radio is pointing to test databases, but still query is running against producion database and hence production services/names are shows in the result.
How do I make it to get the result from test environment ?
Thanks 
Sol:

Generate the master secret from production.

Restore it on test

Update the Secret server name as mentioned below:

File: NewSecretServer.xml
<sso>
  <globalInfo>
    <secretServer>TestSecretServer</secretServer>
  </globalInfo>
</sso>

Run command
<drive>:\Program Files\Common Files\Enterprise Single Sign-On\ssomanage -updatedb NewSecretServer.xml
 
you will have to follow the steps mentioned in this link http://msdn.microsoft.com/en-us/library/ee267632%28v=BTS.10%29.aspx
To update references to the BizTalk Tracking database name
  1. Using SQL Enterprise Manager, open the BizTalk Configuration database.
  2. In the adm_Group table, modify the columns corresponding to the original databases to reference the appropriate values for the new databases.
<DBType>DBServerName and <DBType>DBName indicate the locations of the databases, where <DBType> corresponds to the type of the database: Tracking.
  1. If you are using Human Workflow Services, in the HWS Administration database, modify the HWS_Core table to reference the new locations:
    • TrackingDatabaseMachineName = BizTalk Tracking database server
    • TrackingDatabaseName = BizTalk Tracking database name
  2. In the BizTalk Configuration database, update the BAM Event Bus service to point to the new Tracking database:
    • Using SQL Enterprise Manager, open the BizTalk Configuration database.
    • In the TDDS_Destinations table, modify the ConnectionString column for the rows corresponding to the original database to reference the appropriate values for the new Tracking database.



Read more ...

Configuring SSO in Biz Talk

Wednesday, July 6, 2011
Q : Ho to Configure SSO in BIZTALK Server

Ans :

If you are using local accounts you dont need to create it explicitly. Local accounts are for BizTalk single server environment, however domain groups can also be configured on Single Server Configuration of BizTalk. For local groups make sure you are not giving any domain name before the group name like domain\BizTalk administrators.
For local groups you can use the machinename\Group or just the group name. Make sure those groups are not created already on your computer.
If you want to use domain accounts\groups make sure they exist on the Active directory and the Users are part of that group. For this follow the links

BizTalk installation guide:
Windows Group and User Accounts:

Read more ...