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.
Thought I would share an interesting problem I recently had at work.
Our client has a collection of InfoPath forms it uses to connect to web services for testing BizTalk interfaces from external systems. On the whole, these are pretty stock standard affairs, the relevant BizTalk orchestrations are exposed as Web Services (through the magic of BTSWebSvcPub) and the InfoPath forms (prettied up for client usage of course) submit test messages. This enables them to do pseudo end-to-end testing without having to get half the world involved. Amusingly (amusing because it only just occurred to us), a few days ago I realised we would need to upgrade these forms in line with our BizTalk 2010 upgrade project.
Let the games begin.
As far as things go, it was pretty straight forward. I refreshed the web service references and checked the forms still compiled. So far so good (well, minus a few bits and pieces cropping up, but not relevant to this post). And then came the testing of the forms, and by that I really mean… *head-desk*.
When I clicked the “Submit” button… nothing. Absolutely nothing. Oh Infopath was happily assuring me everything was ok and working awesomely, but on checking BizTalk (and the DB of the relevant application), absolutely nothing. No messages were suspending (BizTalk side), nor were there any validation errors (application side). So a bit of head scratching, a bit of googling and this left me with a lot of issues completely not relevant to my problem. On a side note, googling “vanishing web service requests” unsurprisingly doesn’t yield too much useful information. I also scoured the event viewers of the BizTalk servers and application servers (I even got desperate and checked the event viewer of the machine I was calling the Infopath forms from), all to no avail.
Then I checked the IIS logs of the machine where the web services were hosted, and I spotted a HTTP code Id never really seen; the “202” code. This is the “Request Accepted” HTTP code and means that the server has accepted the request (Yay), and the request (this is important) might or might not be acted upon, as it might be disallowed when processing actually takes place. Initally I thought “Awesome, so its definitely hitting IIS and getting through the web service, so WHY OH WHY isnt it getting through to BizTalk?”. So some more headscratching, googling and *head-desking* later, the penny finally dropped.
Accepted != Ok.
The HTTP codes 202 and 200 are completely different (duh), meaning that while it DID hit the web service successfully, the fact nothing happened in BizTalk afterwards means something must be stopping it in between when it hits IIS and when its supposed to hit BizTalk/MessageBox (keep in mind BizTalk is just a bunch of SQL DBs that require the correct credentials to connect to). This was why I wasnt getting any suspensions in BizTalk, it denying the credentials supplied by the web service as they didnt exist in the DB! So on checking the service accounts that these orchestration web services were using, it stuck out like a sore thumb… I had configured the web services to connect to outside entities using our normal dev service account. While this is ok for our local dev environments (as its what we mostly configure our web services with), I had forgotten that these web services were a completely different beast, and as such should have been configured with the default service account the rest of the IIS Application Pools were using!!
So once Id reconfigured the application pools and fired off an Infopath message, they hit BizTalk (and then the application) successfully! Huzzah!
While this is a bit of a *facepalm* moment for me, I thought it was interesting that in terms of actual ‘error messages’ there were none immediately visible, only the symptom of a vanishing message. It made me look a bit deeper into things than I usually would (in this world of “GOOGLE ALL THE ERROR MESSAGES!!1!1”), and was quite satisfying when I did eventually figure out what was going on. Thinking about it now actually, I think if I checked the DB Server event viewers Id probably find a few Audit Failure events. Hope this helps someone out there with a symptom of (seemingly) vanishing messages 🙂
Our client recently decided to upgrade their BizTalk instances from 2006R2 to 2010, and as we support several BizTalk applications it fell to myself and a coworker to upgrade them. I thought I would share my thoughts and experiences with this process…
Overall the upgrade has gone a lot smoother than I would have thought as BizTalk does have a tendency to be… temperamental. Although to be fair this is more than likely inexperience on my part than any serious fault of BizTalk (although there is one thing which is a Bad Thing, which Ill get to later). I find that (like anything I suppose) once you get your head around BizTalk’s ‘mentality’, troubleshooting issues is a straightforward process. Ok, so lets get into the meat and potatoes of the post :).
Global Assembly Cache
So, the first thing to note when upgrading a 2006R2 solution to 2010 is the GAC is now completely separate for .Net 4.0 DLLs. Yes, that’s right the ‘Global’ Assembly Cache is now two different folders:
– C:\Windows\Assembly [Anything pre .Net 4.0]
– C:\Windows\Microsoft.Net\assembly [.Net 4.0 DLLs ONLY].
So basically, if you have any legacy DLLs floating around, you will have to manage these in the old GAC and the resource DLLs generated as a result of the BizTalk orchestrations/maps/schemas in the new GAC. This is the ‘Bad Thing’ I was referring to earlier, as I find it quite annoying to have to switch between GACs when I’m deploying an application. While I don’t doubt there are valid technical reasons for the split part of me really wishes this could have been handled differently. Ah well.
Related to this, we now have two separate GacUtil executables, one for each GAC. These are located at:
– C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0a\Bin\GacUtil.exe [this is the .net 2.0 GacUtil]
– C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0a\Bin\NETFX 4.0 Tools\GacUtil.exe [this is the .net 4.0 GacUtil].
Third Party DLLs and Resources
This is something that took a bit of effort to resolve. When you have third-party DLLs being referenced in your orchestrations/schemas BizTalk is very specific about how it wants these DLLs deployed. In our case, we needed to register the DLLs in the GAC AND add the DLL as a resource to the application. This is a bit tricky if you are trying to do a first time deployment from Visual Studio (ie. It wont let you deploy the application). So after much stuffing around I decided to write a batch file that handles all of these actions beforehand, after all automation is king 😉 . Once I have a spare few hours I will convert these to PowerShell… mainly because I love PowerShell! But in any case, the end result is that before someone goes to deploy one of our orchestrations, they run the batch file. This batch file will:
– Register the DLL in the relevant GAC.
– Creates a new Application on the BizTalk Management Server DB (more on this later).
– Adds the DLL as a resource to the newly created application.
And hey presto! Visual Studio will deploy your BizTalk application nicely.
BTSTask All The Things!
BTSTask is an executable found in the BizTalk installation directory. This handy little tool can do various things such as:
– Create a new Application
– Add a resource to an Application
– Import/Export Bindings
This was used in our pre-deployment scripts to get BizTalk into a state that Visual Studio doesnt complain. It would be nice if there was a way to do this sort of thing from Visual Studio without having to invoke command line utilities, but at least it gives us something new to learn! Speaking of which, the command line reference for BTSTask can be found here.
So thats the end for tonight. This was just a general overview type post, showing the main three issues/considerations I needed to be aware of when upgrading BizTalk 2006R2 solutions to BizTalk 2010. I will follow up in the next few days with the ‘nitty-gritty’ details, such as considerations for how BizTalk handles the AssemblyInfo files when upgrading the soultion (hint: it doesnt). So thats something to look forward to 🙂