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’.”
The primary file must be at least 100 MB to accommodate a copy of the model database.
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>
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.
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.