All SQL Server Network Protocols are installed by SQL Server Setup, but may or may not be enabled. And you need to be aware that this protocols can have impact in your BizTalk Environment, for example:

• Under certain stress conditions (such as clients accessing SQL Server from the same computer), the SQL Server Shared Memory protocol may lower BizTalk Server performance.
• BizTalk Server loses connectivity with a remote SQL Server computer that houses the BizTalk Server databases and this may happen if the necessary protocols for SQL Server are not enabled.

When you look at Microsoft’s documentation about restoring your BizTalk databases they always talk about restoring your databases by using log shipping. Most of my client have various reasons (unfamiliarity with the technique, requires extra servers and licenses, etc.) for not wanting to use log shipping. Alternatively you can manually restore the BizTalk databases.

My concern with manually restoring the databases is that it can take a lot of time and is prone to errors. By default the Backup BizTalk Server job creates a full backup once a day and a log backup every 15 minutes. Worst case scenario you will have to restore one full backup and (24 * 4) 96 logs times at least 5 databases. That means you will have to do 485 restore actions to restore the BizTalk databases to the latest state!

Some time ago I wrote a blogpost on how to enforce your tracking strategy:

http://www.biztalkadminsblogging.com/index.php/item/84-enforce-your-tracking-strategy-with-a-powershell-script

I did this because one of my customers had a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem was that it was difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifacts this took about an hour of clicking (and was extremely boring).

One of the principal needs for BizTalk Administrators is the ability to monitor the health of BizTalk environments and react promptly to possible problems, you can accomplished this by using certain tools such as: BizTalk Administration Console; BizTalk360; SCOM and many more… However, unfortunately many times, some of these tools are not available for us but we still need to accomplish this task.

In my last post I demonstrated how we could use PowerShell to monitor disk space. In this post I will explain how you can be able to monitoring SQL Agent Jobs in your BizTalk environment using PowerShell.

One of the principal needs for BizTalk Administrators is the ability to monitor the health of BizTalk environments and react promptly to possible problems, you can accomplished this by using certain tools such as:

• BizTalk Administration Console: is a Microsoft Management Console (MMC) that you can use to manage and monitor BizTalk Server, and that you can use to deploy and manage your BizTalk Server applications.
• BizTalk360: that provides a nice user friendly interface to monitoring and supporting your BizTalk environments
• SCOM (System Center Operation Manager) that can provide comprehensive monitoring for Windows systems and with the additional of BizTalk Server 2010 Management Pack, SCOM can offer also monitoring capabilities for BizTalk artifacts and BizTalk-related platform components.
• Many more…

However, unfortunately many times, some of these tools are not available for us but we still need to accomplish this task.

So how can PowerShell help us?

The is a new version of this script. You can find it here:

http://www.biztalkadminsblogging.com/index.php/item/99-new-version-enforce-your-tracking-strategy-with-a-powershell-script

One of my customers has a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem is that it is difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifact this took about an hour of clicking (and was extremely boring).

Final Scripts

It's been the time of my last Post, but not so this is a topic I have left behind.

Remember my previous Posts, in which we were using the PowerShell Provider to BizTalk

Based on the possibilities offered by the cmdlets included in PowerShell provider to BizTalk, we have developed a set of scripts. Each one of them performs specific functions, so it can be executed separately in the environment providing the necessary parameters.

In my last post (http://www.biztalkadminsblogging.com/index.php/item/79-powershell-script-that-gets-biztalk-server-group-settings) I told you that I use library files with PowerShell code that I reuse. In this post I will describe how I import all library files into my script and how the library files actually work.

In my PowerShell scripts I often use the same functionality as in other PowerShell scripts. To prevent me from writing the same code over and over again I created a library with generic code that I can reuse. For example I often need the Management Db Server Name and the Management Db Name.

The script below has a function GetBizTalkGroupSettinginfo that BizTalk Server group settings. It fills variables that you can then use in your script. The script writes the output to screen to give you an idea of the information that is collected.

It’s always good to know what software is installed in our environment. Sometimes we need to know what version of BizTalk is installed or what version of the Adapter Pack, x86 or x64?

And preferably be able to get this list in an easy and automated way.