Archive | Configuration RSS for this section

Configuring the ESB Toolkit 2.2 for BizTalk 2013 – Exception Creating the ExceptionDb

One of the great things about BizTalk 2013 is the improvements made in the installation of the ESB Toolkit.  However, we’ve found lately, that there are still some issues that you should be watching for during configuration.

One issue, which I’ve seen twice now, has shown up while completing the very first configuration step in the ESB Toolkit 2.2’s configuration utility–creating the Exception Management database.  Our configuration failed with this exception: 

Exception Calling “create” with “0” argument(s) “Create failed for database esbExceptiondb’.”
Generally the first thing we do is figure out if there are security issues.  In particular, we need to make sure that the account we are logged in with has all the correct rights on the SQL Server.  In my opinion, it’s probably best to have SA privileges while completing the configuration, but I’m sure there are plenty of DBAs who would argue with me on that.  We were able to verify that, in fact, we were operating under such an account.
 
That led us into the configuration tool’s log file, which gave us a much more helpful hint: 
The primary file must be at least 100 MB to accommodate a copy of the model database.
The source of the problem seems to be a powershell script, embedded into an .exe, that sets the size of the DB.  Because the value is “hard-coded” into the uneditable script, the other option is to shrink the model db. Once you connect to the SQL server, you can find the model db under System Databases in SSMS.
 
First, before you go any further, BACK UP THE DATABASE. 
 
You can use SSMS to perform the shrink.  We found that running a shrink script didn’t work as well.  So in SSMS, you just right-click the database and select Tasks -> Shrink -> Database.  Then configure the options to get the DB down to a more manageable size.  You can find an MSDN article on using SSMS to shrink a database here.
 
This worked for us right away and configuration of the ESB Toolkit was able to be continued.

Could not contact the SSO server

I started getting my hands dirty with BizTalk development after a few months of working as an architect (in the drawing pictures and writing documentation sense).  It’s good to be back!  Unfortunately, it also means that I get the fun of setting up my BizTalk configurations again.

While trying to load some settings into SSO through the Deployment Framework (http://biztalkdeployment.codeplex.com), I got this beauty of an exception:

Could not contact the SSO server ‘(local)’. Check that SSO is configured and that the SSO service is running on that server.
 (RPC: 0x800706BA: The RPC server is unavailable.)

The same error also showed up when I tried to run the SSO Admin utility as well.  My first reaction was to check my BizTalk configuration to make sure that everything looked good.  I saw the pretty “Green Check” next to SSO in the configuration list, so I guessed (correctly) that it had nothing to do with my BizTalk configuration.

But the fact that I was using the server ‘local’, did make me wonder.  I know this works ok with SQL Server, but using the shortcut (local) to refer to a database server is problematic with SSO.   To set things straight, I just had to run the SSOManage command-line utility and set the server to the local machine name instead of using the term “(local)” and that fixed the problem.

So, here’s the command-line fix:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage -server <machineName>

or


C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage -serverall <machineName>

You can then run the same utility with the -showserver command-line parameter to make sure that it took. Below is an image of the results on my machine.

SSOCommand

Don’t “Pretty Print” the Filter Section of Your BizTalk Bindings Files: Exception from HRESULT: 0xC00CE557

Watch your bindings files!  If you do the typical thing and export your BizTalk bindings files from the Management console, be careful not to “pretty print” the Filter portions of the output when looking at it.  Doing so may cause BizTalk to generate the following:

Could not enlist send port YOUR_PORT_NAME Exception from HRESULT: 0xC00CE557

BizTalk doesn’t like having a CrLf as the first character in the Filters section.  So if you’re taking a peek at the bindings file, be careful when you’re using a word processor or text editor other than Notepad and especially so when using the Visual Studio XML editor!

Thanks to Shankars  for the helpful post that discusses this problem!

Should you accidentally load the file in the VS XML editor or a text editor that likes to “help” you with a pretty-print, you can  fix this problem without re-generating the bindings file.  Simply delete the CrLf characters in the first part of your filter definition in the file. Just delete the characters until the first character in the filter is flush with the <Filter> tag.   There is no need to put the entire filter on a single line as mentioned above.

%d bloggers like this: