When the BizTalk Best Practice Analyzer starts it tries to connect to the internet to get an update of the latest best practices. However, quite often servers do not have a direct internet connection. This will result in the following error:

 
Within time this will leave you with a BizTalk Best Practice Analyzer that uses outdated best practices.

Over the years we have seen so many common challenges in an enterprise environment when it comes to BizTalk environment day-to-day operations. Here are the top 7 challenges, we have seen.

1. Remote Desktop access to physical production servers

2. Ability to start/stop BizTalk artifacts, Host Instances, Service instances without any audit trace

3. Access to production SQL server instances

4. No or minimal monitoring of BizTalk environments

5. No idea whether your environment is working optimally or throttled heavily

6. No read-only access support

7. No way to isolate application data in a shared environment

In below sections we will explain a bit about each section and see how BizTalk360 can help address all these old practices.

One of my clients asked for an easier way to stop and start BizTalk applications. I created a PowerShell script with a Windows forms GUI. You can use it to stop or start all host instances and or IIS on a server in a BizTalk group.

When it comes to performance analysis you can get overloaded with performance data. Manually analyzing it takes a lot of time. Analyzing it can be difficult. Most admins know that an average cpu load of over 80% is seen as problematic. But at which value does Memory Pages/sec or Process Private Bytes starts to be problematic?

The Backup BizTalk Server job uses the MarkLog table to write marks. These marks are actually timestamps which are used by the job to determine until what time a (Log) backup must be made. Unfortunately BizTalk has no out-of-the-box possibilities to clean up that table.

Luckily Microsoft provides Terminator to clean up this table and do a lot of other things. In this article I’ll describe the capabilities from Terminator in short and more detailed on how you should use it to clean up the MarkLog table.

The MessageBoxViewer MBV is one of the main tools we have at hand to manage and monitor our BizTalk environments. This tool has been created by Jean-Pierre Auconie, and is currently available in version 11.

I recently saw a presentation from Saravana Kumar about BizTalk360. He showed the product and some of the new functionalities. This presentation inspired me to do some testing with BizTalk360 and write a blogpost about it.

As most of you will know BizTalk messages and context are stored in the MessageBox and the Tracking database as Image types. By several people a number of posts have been written about decompressing BizTalk messages and their context and here's another one!

When we had an incident with quite some suspended (not resumable) instances, we needed to retrieve message content and context. This information should be used to take appropriate actions for damage elimination.

After a search I found this great article from Thiago Almeida. It even contains a sample solution! Good news though for an intermediate developer as me!
I've been working on the solution and made it use just the SQL method. My goal was to create functions in C#, that would decompress the fields that contains the message and the context and enable the user to use these functions in SQL queries they entered in a textbox.