Firstly, I knew it had been a long time since I posted on my blog, as I have been snowed under with work for my current client and none of this work warranted any posts on the subject. However, I must admit I didn’t realise how long ago it was since I actually posted. Doesn’t time fly huh? I can’t say I know where this year has gone, but we all say that every year don’t we?
Anyway, I solved a relatively simple (but annoying) problem today that I hadn’t encountered before that didn’t have much information available on the internet; well, not for my particular scenario. So I thought it would be worth popping on my blog, firstly as a simple wave to say I am still alive and secondly as a reference for me in the future. You know how it is, you spend time solving problems then encounter them a few months later only to forget how you solved it. Well, I feel the blog is a good repository for this kind of information.
So, what was the issue? Well, one of our testing environments had taken a bit of a pounding recently with various non-functional tests. This is never healthy if you wish to come out at the end with the exact same environment as you started without some form of rebuild be it automated or not. While trying to deploy a custom adapter to this environment numerous errors were occurring, which led to the conclusion that there was in issue with SSO. A highly likely conclusion considering one of the non-functional tests included the restoration and movement of SSO.
During the investigation it was observed that whenever you tried to register a new adapter you would receive the following error:
SSO AUDIT
Function: CreateApplication
Tracking ID: e902339c-b431-40e5-a880-337bb873725b
Client Computer: <Computer Name> (wmiprvse.exe:1232)
Client User: <User Name>
Application Name: {11C54F41-4C5A-4929-B828-7CD6E550BEB8}
Error Code: 0xC0002A18, The format of the account name is not valid. Domain accounts must include the domain name. Local accounts must not include a domain or computer name.
This naturally led to an examination of all things related to SSO, in particular the SSO services. You would have thought from the error message that the service account used for SSO was incorrect. However, after too much time it transpired that the default BizTalk Host was registered using an incorrect domain group; it actually wasn’t in the domain as per the above error.
And the conclusion to this little story? Spend a little more time studying the GUIDs in the error. Only in hindsight did I think about searching out the details to find they would have guided me to the answer more quickly.