I suspect that many organisation don't yet realise this, but "BizTalk Administrator" is a now a specialised job role. So often I see situations where, when things starting going wrong, the operations guys are forced to call in the BizTalk dev guys because they're the only one's in the company who have a firm grasp on how BizTalk works. Maybe that works in your organisation, but its worth pointing out that dev guys aren't necessarily well suited to making stuff run. Devs build stuff. Operations people keep stuff running. Its different mindsets, and if your critical BizTalk infrastructure (or something BizTalk is dependant on) is currently down (it happens), do you really want mindsets clashing?

What would be the hallmarks of a good BizTalk administrator?

• Well for starters, a good BizTalk Administrator would actually realise they are the BizTalk Administrator. They understand that its a specialised skillset and requires specialised knowledge.
• They've done some BizTalk Administration Training (company funded of course) and they've read the operations manual.
• They actually have a BizTalk install on their own box which they play with. They may not have the dev background to get too involved with orchestrations maps and all that dev stuff, but they play with the SDK samples when they can.
• They fully understand the Deploy Undeploy story around BizTalk and the various methods available for deploying artifacts.
• They understand the relationships between, BizTalk and IIS, BizTalk and SQL, BizTalk and MSMQ, BizTalk adapters and everything they connect to, and so on. If you connect to a mainframe, they should have some idea how that magically happens.
• They are plugged into the BizTalk blogosphere/newsgroups so they can keep a proactive watch out for issues, releases, Services Packs etc. No good BizTalk Administrator would be surprised to hear that BizTalk 2004 Service Pack 2 released recently (You already have this in your maintenance/release plan don't you?)
• If you've got BTS2006, then they hang out in the BizTalk Administror Hub page for a part of the day...you know just keeping an eye on things... If you have BTS2004, then they are intimately familar with HAT and use it daily. A really good Admin will even have custom HAT queries they use for looking at things of interest.

This has been my 2 cents.

Mark

No organisation in their right mind would install a non trivial SQL Server system without furnishing a qualified DBA to look after it. Why do organisations not treat BizTalk in the same way?

On a scale of 0 to 10 where zero equals "If BizTalk stopped working someone might notice after a couple of weeks" and 10 equals "If BizTalk got borked, we would lose ELEVENTY BILLION DOLLARS every 10 mins" where is your BizTalk installation?

If the Business impact of a BizTalk failure is low, say less than 2 or 3, then maybe this post doesn't apply to you. Anything greater than 3 and you would do well to heed the following advice.

BizTalk isn't a trivial product. Neither from a developer perspective nor an operations perspective. Its really important that the operations people responsible for keeping BizTalk running are adequately trained and knowledgable on how it works, what all its moving parts do, how to backup and restore etc. The worst case is when a Windows infrastructure guy (or team) or a SQL DBA is given the responsibility for managing BizTalk but isn't given the training to do the job properly. Yes its a Windows Server product and Yes it uses SQL Server extensively but neither of these two groups of people are necessarily well qualified (with out specific training) to maintain a BizTalk installation.

At the very least, BizTalk operations people should be FORCED to read the manual - and given the time to get comfortable playing with BizTalk (not in production of course!).

There is BizTalk administration training available from various places (Microsoft included) . I would say if your BizTalk installation is greater than a 5 on the business critical scale, proper formal BizTalk administration training for the operations team should be MANDATORY. (If for no other reason than as risk minimisation).

And my last question as I round out this post is: When was the last time your BizTalk Operations Team  did a BizTalk failure/restore drill?

I would say, take your number on the scale, divide it by 2 and thats how many times per year you should run a restore drill.

Mark

Ps: ELEVENTY BILLION  is my favourate fictional number.

The BizTalk Server HTTP adapter does not support having the login credientals in the URL.

For example, you can't have a URL like the following configured in the HTTP send port.

https://www.example.com/webservice.aspx?fileType=MyFile&by=username:password

If you do that you will get an error like this:

Obviously having the credientals in the URL is a very bad idea but if you absolutely must do it, you could configure a dynamic send port and supply the URL at run time. Alternatively, you could write a pipeline component which appends the login details to the URL.

Mark

The top 3 things SQL DBAs need to know about BizTalk. (In order of importance)

1. BizTalk Server has its own backup story and SQL DBAs need to become fully acquainted with it. Do not assume that the normal SQL Backup tasks will adequately backup your BizTalk Server. The BizTalk 2006 documentation is comprehensive in this area. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts06coredocs/html/82fc1af2-1389-4c79-80dc-f2df5656d201.asp
2. There are several things about the way BizTalk uses SQL Server that are unusual.
   1. http://support.microsoft.com/kb/899000/
   2. /http://support.microsoft.com/kb/912262
   3. The SQL Server Agent must be allowed to run continuously on the server hosting BizTalk databases.
3. BizTalk uses SQL Server extensively during normal operations. Try to ensure BizTalk and SQL Server are separated by as few network hops as possible.

"Hey Mark, whats with the name of this blog?" i hear you ask. Well I'm glad you asked. In most dialects of English, Torque and Talk are pronounced pretty much the same. "Torque" connotates torque wrenches, car mechanics, engine oil soaked overalls and down to earth hardwork. And thats pretty much what this blog is about. Except for the wrenches, mechanics and overalls. This is kind of place you'll want to come when you want to make sure your BizTalk Server is tuned up and running right.

Now that I've thrashed that analogy you wont have trouble remembering that its like "BizTalk" but with "Torque".

And before you ask, the .com was taken already.

Mark

There are alot of BizTalk blogs available. I find that most of the content focuses on architecture and development and there is little content available for those of us tasked with keeping BizTalk running. This blog will hopefully address this gap by focussing on things that will be relevant to BizTalk Administrators and everyone involved in BizTalk operations. That being said, I do get quite a variety of interesting BizTalk issues in my day to day work so I expect my posts will hit a wide cross section of BizTalk stuff.

A personal intro:

Those of you who come along to our Sydney BizTalk Usergroup, will know me as one of the organisers. If you're in Australia or New Zealand and you've raised a support case with Microsoft on BizTalk in the past couple of years you would have probably had me on the other end of the line.

I've been working with BizTalk Server since early 2000 when BizTalk 2000 was in beta. In fact, I can remember downloading Alpha BizTalk bits when all that existed was the developer's workbench sweepings. I've lived through all the version upgrades. I've passed both the BizTalk 2004 and 2006 certification exams. I've toyed with the idea of going back and sitting the BizTalk 2000 exam just for completeness :-).

One of the reasons its taken me so long to get this blog up and running is that I've been up to my eyeballs in study: www.itmasters.com.au. I'm currently about half way through.

Expect a flurry of posts over the next few weeks while i get the pent up content ideas out. After that things will settle down a bit.

I would of course appreciate folks linking to my blog so I can get an audience.

Feedback always welcome.

 Mark

Hi All,

Welcome. This has been a long time coming but I'm finally up and running with my BizTalk blog. As such, I have alot of pent up ideas for blog posts i've been wanting to make so i will start posting these as time allows.

Mark