BizTalk Errors ENTSSO, Desparately seeking solution

[kris]

Some Know-It-All/Have-Button-Will-Click Admin came in and turned on
password aging on all the BizTalk related users and did some other
stuff that I'm not aware or. Now I'm stuck with all these errors

SSO AUDIT Function GetconfigInfo
Client User: MyDom\Biztalk Host Instanc
Error Code: 0x80004005 Unspecified error

Event ID: 5641
The Messaging Engine failed to retrieve the configuration from the
database.

The Messaging Enine encountered errors while initializing the send
adapter "FILE"

The Messaging Enine encountered errors while initializing the send
adapter "FTP"

and rest of the adapters.

I've done lot of googling and msdn search but could not resolve my
specific issue.

Please help.

[kris]

During the process, somehow the mastersecret key was lost and I had to
create a new mastersecret key to have the sso service running.

[Michael Elizarov [MSFT]]

Kris,
As I understand you fixed SSO issue. For other accounts you can change
accounts used for running hosts from the administartive console.
-- Michael

--------------------

[kris]

Michael,

I'm a bit lost here. What do I need to change for other accounts that
would resolve my issue?

Kris--

[Tomas Restrepo (MVP)]

Hi Kris,

> During the process, somehow the mastersecret key was lost and I had to
> create a new mastersecret key to have the sso service running.

I'm afraid that was possibly the worst thing to do. When you change the
ENTSSO user password, you loose the master secret, which is stored in the
user's registry encripted (in an LSASS secret), and so, loose access to the
SSO database. When that happens, you need to go in with ssoconfig.exe and
restore the master secret key on the master secret server using the key
backup (you *did* have the backup, right?)

However, if you go ahead and tell the SSO to generate a new key, it will go
ahead and do so... and in that process completely destroy the contents of
the SSODB (at least in my experience). The problem is that when you tell it
to generate a new key, it normally uses the old key to decrypt the DB
contents and then encrypts them again with the new one. Since the old one
was missing (or possibly corrupted, who knows), it decrypts the DB contents
into gibberish, thus ending up with a bunch of things in the SSO DB that
doesn't make sense anymore.

In that scenario, I'm afraid your biztalk configuration is hosed for good,
and the only way to recover it is to unconfigure biztalk
(ConfigFramework.exe /u) and reconfigure it again from scratch, then
redeploy your applications.

--
Tomas Restrepo
tom...@mvps.org
http://www.winterdom.com/

[kris]

Thanks for the post Tom. I am mulling the option of reconfiguring
biztalk and redeploy all my orchestrations. Its just frustrating that
the biztalk 2004 product installation and maintenance is a nightmare
and not well thought out all.

My only worry is that if configframework fails for "any" reason, I will
be completely hosed and I will be looking to re-image the server(s). I
am trying to avoid that scenario.

[Michael Elizarov [MSFT]]

Kris,
I guess we got out of sync ;)
My understanding of your situation is the following: you have accounts that
have expired passwords. That prevented you from using SSO and starting any
services. You have fixed problem with SSO by recreating master secret DB,
but your host instances are still not working. Correct?

If you still have hosts that use accounts with invalid passwords, you can
start administrative console, go to host instances and configure account
information.

Does this answer your question?

-- Michael
--------------------

[Tomas Restrepo (MVP)]

Hi Kris,

> Thanks for the post Tom. I am mulling the option of reconfiguring
> biztalk and redeploy all my orchestrations. Its just frustrating that
> the biztalk 2004 product installation and maintenance is a nightmare
> and not well thought out all.

It is not so much of a nightmare, but I agree it is a fairly complex
procedure. The SSO thing itself is probably one of the ones that cause more
problems as well, and one of the issues here is that there is not so much
information about how to keep it running reliably, and, more important, how
to recover a hosed SSO configuration. I just happened to have learned this
the hard way :)

My current thoughts on this are actually simple: Never, under any
circumstance, regenerate the master secret, except under one extreme case
and that is one of a security breach and you better know what you're doing.
Other than that, keeping your master secret backup and the SSODB backup will
go along way towards helping you restore your ENTSSO environment.

> My only worry is that if configframework fails for "any" reason, I will
> be completely hosed and I will be looking to re-image the server(s). I
> am trying to avoid that scenario.

Well, I'm not sure why you say that; it should've screw you completely (and
I've dealt with quite a few failed configurations before and never seen
that). That said, you might be happy (or not so much ;)) to know that a lot
of effort has gone in BTS 2006 to make this process a lot more simpler and
easier to recover from. For example, the config framework tool is now
reentrant, so if one part of the configuration fails, you can go back to it
and reconfigure just *that* and not the whole thing.