Terminal Services and the BizTalk Administration Console

One of the problems at work we faced a while back as our BizTalk developer pool grew, was an increased need to allow users to simultaneously work on the same BizTalk Server. Some of the time users need to deploy new things on the server, but the grand majority of the time they simply needed to resume suspended messages, kill messages, etc. (we all know how this goes, right?).

Until this time, our current process involved having each user use a Remote Desktop Connection to connect to the server, do whatever administration they needed, and then, if we were lucky, they’d log off. We only had two Terminal Service licenses (the default for remote administration), so of course now and again, people didn’t log off, or at least didn’t do so properly and then we’d have a problem on our hands. Emails would go out trying to figure out who was accessing the server so that the next poor guy or gal could start their work. As a response, we did a few things to help.

First, we modified the Terminal Services configuration to end disconnected sessions quickly and we closed sessions that had been idle for an hour.

Of course this helped a great deal, but it wasn’t enough – we actually had a real need to have several users logged in at once. So then we heard about the “secret” third terminal service connection.

Basically, the secret third terminal service connection is the console. By adding the “/console” appendage to the otherwise ordinary Remote Desktop Connection command, e.g. %SystemRoot%\system32\mstsc.exe /console, you can get a third person in on the box. As a note, you probably want to avoid using “/console” unless you need to get on the box, as it will force the previous console user out. Nonetheless, you now have 3 remote users! In this image you see I have successfully logged in thrice; the green user indicates the console (or so I presume):

This last approach is a little bit of a hack, but nonetheless nice to know. Now, here’s the real exciting part for BizTalk administrators…

As I mentioned, most of our developers were logging into the various servers to simply resume orchestrations, kill messages, and so forth. This is when a fellow teammate, Richard Seroter, looked into better utilizing the Microsoft MMC capabilities. This approach doesn’t require the users to log into any of the various servers to do their administration tasks. Rather, from a single console, all BizTalk Servers the user has access to can be managed. Similarly, assuming the user has access to the event logs of the particular server, the event logs of each server would also be available.

To get started, install BizTalk Server with just the minimum number of components (may not even be necessary if your using your own pc for BizTalk development). In my setup I added the additional software component of Enterprise Single Sign-On Administration Module.

Next, download the Microsoft Management Console for your OS. Mine is XP, so I found it here. Then, you can either modify an existing msc file (why didn’t MS choose mmc?) or create a new one. To modify, throw in the /a to the mmc command, e.g. mmc /a whatever.msc. To create a new one, just run the command ‘mmc.exe’. Next, choose File->Add/Remove Snap-Ins.

In the screen above I am setting up administration for any number of BT servers (I’ll later setup 2) and 2 Event Log viewers (one for each remote server). After pressing OK you will then need to add a BizTalk Server group, which I won’t go into here…

So what’s the final result? The ability to monitor two (or more) servers from a single console without having to log into any of the servers. This has saved me a lot of hassle. Now our developers only login to the various servers when they need to deploy a new msi file. Consequently our terminal services use has declined dramatically.

Oh, one more thing to note, if you use any other adapters, e.g. Siebel, Oracle, etc., you will need to install the basics of the adapters on the machine with the MMC as well. Good luck!