BizTalk, Configuration, Installation

(Not) Using Built-in Service Accounts for BizTalk Server

Recently I tried installing BizTalk Server 2010 in a pretty locked down environment – as in no accounts except a few domain accounts were given the “log on as a service” right. Thus as a first go I was left trying to use the default accounts on the machine.

These are my short summarized findings trying to run BizTalk using built-in accounts:

  • SQL Server – Can run as Local System or Network Service. NOT as Local Service.
  • SQL Server Agent – Can run as Local System or Network Service. NOT as Local Service.
  • For more SQL Server account info see this link.
  • The SSO service – can NOT run as Local Service or as Local System.
    It can run as Network Service, although there are some special requirements – namely: the SSO Administrators group must be pre-created, the Network Service account added to it and the computer restarted.
  • BizTalk Server Runtime – Can NOT run as a any form of local built-in account.
  • At this point I guess I could have gone on to try the other sub-services as well, like BRE, but why bother… Lesson learned. You cannot configure BizTalk Server using only the built-in accounts. Also this link from the BizTalk documentation clearly states that these accounts are not supported, though it is non-specific.

Quoted info on what these built-in accounts mean:

Local Service Account

The Local Service account is a built-in account that has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard the system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session without credentials. Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services. The actual name of the account is "NT AUTHORITYLOCAL SERVICE".

Network Service Account

The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITYNETWORK SERVICE".

Local System Account

Local System is a very high-privileged built-in account. It has extensive privileges on the local system and acts as the computer on the network. The actual name of the account is "NT AUTHORITYSYSTEM".

BizTalk, Configuration

My BizTalk infrastructure design baseline

How should I design my environment? What OS version? SQL Edition? BizTalk license? Etc. Etc. I get these questions frequently.

The only one true answer to this question is the architects favorite – “it depends”. And once you know the requirements – some of the things on which it depends – it will still be closely followed by its companion: “We need to test to know”.

Still, I think everyone has their favorite configuration – that they then add or deduct from based on the requirements. I do. This is how it goes.


Four. Two SQL, Two BizTalk.
Why? High availability for SQL and BizTalk. Load balancing on BizTalk machines.


Windows Server 2008 (R2) Enterprise, on all machines.
Why? Clustering. Plain and simple.

SQL Edition

SQL Server 2008 (R2) Standard, on the SQL boxes.
Why? Off the BizTalk environments I have worked with they have only very seldom gone beyond two machines which is the only real limitation with Standard that I care about. I know of limitations to RTA in BAM and of performance gains with Enterprise, and sometimes that may be required – but not as a baseline.

SQL Instances

Four SQL Server Instances: BizTalkMgmt, DTA, BAM, MsgBox.
Why? Prepare for and maximize scale-out possibility. Simplify IO division. Help with memory reservation.


Three disks per instance: Data, Log and TempDb. Baseline is 40, 20, 15 GB. Varies with requirements.
SAN if available.
Why? Disks are un-expensive. IO is core to SQL. SQL is core to BizTalk.

BizTalk Edition

BizTalk Server 2009/2010 Enterprise
Why? Number one reason – you want to be able to go beyond a single server: Because you want load balancing and high availability.


Not in my baseline.
Why? Could be a requirement with certain customers and it certainly works, but I would recommend physical machines because I think it gives more bang for the buck. BizTalk can many times be a processor, memory and IO intensive application.


Quad cores for sure, Hexa or Octo if availability permits. One proc per server is enough with this amount of cores as a baseline. Requirements like high throughput messaging and processing may cause it to rise.
Why? Same as above. Higher ROI with multi-core.


4 GB minimum for a 64-bit OS, preferably 8GB or more total memory on BizTalk Servers.
At least 16GB on the SQL machines.
Why? Memory is a cheap commodity right now. Not the right place to be cheap.


The above is in no way thorough. It wasn’t meant to be. There is no “One Truth”. I stress that I call it a Baseline. It was meant to be a brief overview. It’s based on the most common questions and the most common requirements for my customers. Consider your own requirements. Mine might not match yours. “It depends”…


What’s your baseline? Where does it differ? Where have you drawn the same conclusions?

BAM, BizTalk, Configuration, Installation

BAM and SSIS notes worth repeating

SQL Server Integration Services (SSIS) is not a clustered resource. Connecting to SSIS generally means connecting to any of the SQL Server servers in your cluster environment directly, not to a virtual cluster address. Configuring SSIS for a named BAM instance still involves configuring it against your clustered BAM database instance. The BizTalk install documentation (Multicomputer) also claims that SSIS needs to be installed on the BizTalk Servers. That’s incorrect. You could install SSIS and that’d be good, but I much rather install the management tools, as explained and outlined here.

While talking about BAM I can’t help but to mention an excellent article recently written by Saravana Kumar here.

Configuration, General, Maintenance, Monitoring

Event log service is unavailable issue

I thought I’d blog about this issue I had, since it was in the end so easy to solve, but I had a hard time finding a good description of both my specific problem and any resolution. I am a bit ashamed to say that I got quite creative before trying this.

The problem I was having was that when opening the Event Viewer on my Windows Server 2008 I’d got a message saying that “The Event Log service is unavailable. Verify the service is running.“. And if I went to look it was in fact not running. The thing is though that I could easily start it, and it would keep running, until I went to the Event Viewer to look at the logs, which would then bring it down.

I solved this by simply deleting all the files in the C:WindowsSystem32winevtLogs folder.

Update 2010-02-22: Feedback in comments suggest that you might need to restart after performing this step.  

I’m not going to patent the solution, or make the claim that it will work in every case, but it did for me, and if you are experiencing this problem it’s easy enough to try.

BizTalk, Configuration

Q: Can I run BizTalk Server 2006 R2 on Windows Server 2008?

Q: Can I (should I) run BizTalk Server 2006 R2 on Windows Server 2008?
A: No. And these are the main resources I give customers who wants to see some kind of Microsoft reference to this:

Q: Can I (is it technically possible to) run BizTalk Server 2006 R2 on Windows Server 2008?
A: As I mention (but perhaps do not emphasis) in the answer to the first question of this post “Can I (should I)” is an answer directed at customers. From an technical aspect it is possible to install and run at least the main parts of BizTalk Server 2006 R2 on Windows Server 2008 (see this post), however it is not supported. As such the answers to customers is (so far) still no. But then again up until quite recently it wasn’t really supported to run BizTalk Server virtualized on VMWare either (but now it is) and we still did that so maybe I’m being over-cautious? It’s not the same kind or level of support we are talking about though…

Q: Can I (should I) run Windows Server 2008 as the host OS on which I run virtualized guest OS with BizTalk Server 2006 R2 though Hyper-V?
A: Yes. As long as the guest OS is compatible with BizTalk Server 2006. Ie Windows Server 2003 (, XP or Vista). See the BizTalk Server 2006 R2 Hyper-V Guide.

UPDATE: I updated this post after comments. Thanks Jocke, it’s certainly more complete now.