Bit of a hiatus since my last post, but life has been pretty busy lately. Started a new job recently (yay!), so Im currently settling in which hasn't left me with much time for personal development.
I've been asked to do a basic presentation on BizTalk, introducing my new team to its basic concepts and what its used for. Im currently in the process of setting up a couple of demos, and (as always) BizTalk is giving me fun and games getting the darn thing set up. Again, as always its my fault rather than BizTalk's, so here's a couple of things I've just run into which I thought might help someone out there.
The first of these is the following error:
Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSOC7B0.bak (SSO) : Access Denied.
The cause of this is (thankfully) quite simple: the account you've just configured BizTalk to use doesn't have the necessary privileges on the machine to complete the configuration of the SSO component of the BizTalk installtion (provided you've selected SSO as one of the installed features). So once I'd added my BizTalk user to the Administrators group, that error message went away. Interestingly, when I went to re-configure the BizTalk installation it warned (!) me that the account had administrator privileges and posed a security risk to the box. So this makes me think the BizTalk service account doesnt actually need admin rights, but instead a particular subset of permissions slightly more elevated than normal. I dont particularly care right now, as I'm just trying to get the bloody thing up and running, so thats a post for another day :)
The second error was surprising, and was one of the validation errors BizTalk scans for when beginning a new configuration:
SSO DB already exists [this isnt the exact wording as Im trying to do this from memory].
Ok, so this part is really important: Restart your SQL Server Instance. Until you do this SQL doesnt play nice with the SSO DB (or more likely the newly created SSO Windows Service isnt playing nice), so restarting the SQL instance clears any crap left over from your attempted install. That should then let you drop the DB to avoid any further issues, otherwise there will be services that are holding connections to the SSO DB from the failed install.
The third (and last) of these errors was:
Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSOC7B0.bak (SSO) : Access Denied
Look familiar? Yep, exact same error as the first one, but the cause of THIS was different, and far, far more annoying. I actually got to the point of uninstalling BizTalk several times (along with Enterprise SSO), multiple reboots, SQL instance restarts. Nothing. It kept failing on the same point (ie. the start). So I started looking a bit deeper into the log file, and found a permissions error related to the local account I was running on (not the BizTalk service account), saying access denied. "Strange", I thought. "Im an admin on this box, BizTalk even allowed me to restart the WMI Service!" (this is amusing to me, because trying to install BizTalk on my local work pc was a bloody nightmare... thats a story for another day).
Then I had an idea... when I originally began to configure my BizTalk installation my service account it spat an error at me saying I couldnt use an account to configure BizTalk that had no password. So I created a password for it, and it went away. I realised at this point that Server 2008 r2 was logging onto the main account WITHOUT a password. So obviously, it must realise that my local account didnt have a password, and as such wasnt playing nice with SSO (hence why BizTalk spits an error when you try and configure a service account for it with no password). Would have been nice for BizTalk to tell me that at the start, but its ok. Once I set a password for my local account (which, silly me, I should have done from the start), the configuration worked perfectly! Ive now blogged this hellish issue, so it wont be an issue anymore :) (or at least as big of an issue haha).
Hope this helps some poor BizTalk dev out there.