RSOR - MoM Rules/Alerts targeted to a particular agent

RSOR - Resultant Set of Rules is an excellent utility to get the set of MoM rules/alerts targeted to a specific client. Thanks to Tom Keane from Microsoft who is the author of this utility. We use this utility more often in our development servers where we frequently add rules/alerts. In development, this utility can help us to ensure the newly added rules/alerts have been reflected in the MoM database or in production this can help us to identify the list the rules/alerts targeted for a specific agent without using the admin-console.

Syntax:
RSOR.exe <MOMDBServer[\instance]> <TargetAgent>

Ensure that you have enough permission to read the MoM database or use a login which has got at least read access to the MoM database to execute this utility.

After executing the above command, check for “ResultantSetOfRules” folder in the root directory where you have copied this utility.

Reference:
http://technet.microsoft.com/en-us/library/cc180050(TechNet.10).aspx

Read the following article for essential tool for MoM:
http://technet.microsoft.com/en-us/magazine/cc160922.aspx
Reference:
http://technet.microsoft.com/en-us/library/cc180050(TechNet.10).aspx

Read the following article for essential tool for MoM:
http://technet.microsoft.com/en-us/magazine/cc160922.aspx

Remove a BizTalk server from BizTalk server 2004 group

You must have SQL 2000 Server system administrator rights or BizTalk Server 2004 administrator rights to follow these steps. These steps would only be performed on the BizTalk Processing server has failed as is being replaced.

1. Start the BizTalk Server 2004 Administration snap-in.
2. Expand Servers.
3. Click the computer that is not working.
A list of the host instances that are associated with the computer that is not working appears in the results pane.
4. Right-click each host instance and then click Delete. Repeat this step until all the host instances that are associated with the computer are deleted.

Note: You receive the following error message when you try to delete a host instance that is isolated;

Failed while deleting the Windows NT service BTSSvc {F46166EC-B4B8-4129-AB86-F3BB212CEC50}

You receive the following error message when you try to delete a host instance that is in process;

The network path was not found

If you receive one of these error messages click OK. After you click OK you receive the following error message;

You can forcefully delete this host instance. This may leave orphan orchestrations and prevent cleanup of COM+ applications and NT services on machine ‘computer name’. Do you want to proceed with forceful host instance deletion?

If you receive this error message click Yes.
5. Click Start and then click Run and type wbemtest.exe and then click OK. Hope wbemtest.exe should have already installed in your server.
6. In the Windows Management Instrumentation Tester dialog box click Connect.
7. In the Namespace text box type root\microsoftbiztalkserver and click Connect and the click Enum Instances.
8. In the Class Info dialog box type MSBTS_ServerSetting under Enter superclass name and click to select Immediate only and then click OK.
9. In the Query Result dialog box click the computer that is not working and then click Delete.

Note: You cannot delete the server instance if the server is associated with any host instances.

Problems faced while installing BizTalk Server 2004 – Service Pack 2 (SP2)

It always had been a tough time when we installed BizTalk Server 2004 – SP2 on our servers. Thank god we have a good pre-production environment similar to the production server to try our hands. The lessons learnt are really a good experience.

* Before you apply the SP2, make sure that you have backup for all, off-course this should be the norm for any service pack installation. In BizTalk 2004 SP2, for some reason if you want to uninstall the SP2, it uninstalls the SP2 binaries and restores the BizTalk Server binaries to their SP1 state. SP2 contains major database schema changes and uninstalling SP2 does not restore BizTalk Server databases to their SP1 state. So you must restore the BizTalk Server databases from your backup.

* One at a time. If you have farm based set-up for your BizTalk Processing servers and all access a single cluster for the BizTalk database, ensure that you install the SP2 at one BizTalk server at a time. As said, SP2 contains major database schema changes and if you do the installation of SP2 on more than one server at a time (just to save sometime) there are high chances for your BizTalk databases to crash.

If the installation fails with some error, the SP2 executable package is expected to roll-back all the changes it had done till the failure. It doesn’t seem to be proper always. I have seen scenarios where the host instances were disturbed and all the in-process instance will appear as isolated host instance. In this case to recreate the host instance, you have to delete the instance from both the admin console and also from the services tray (services.msc). To delete the services from the service tray use the following command:


SC delete <<BizTalk Service Name>>

* "bts_CleanupMsgbox" is empty (or just with stored procedure structure without and process code in it) by default. Microsoft doesn't suggest by default to use this SP because of its seriousness in purging the "live" data, but for our operational reasons we decide to go ahead in using this SP, this has to be created explicitly. Microsoft provides the SQL-script to create this SP which can be located at

<BizTalk installation directory>\Schema\msgbox_cleanup_logic.sql

from the BizTalk processing servers.

So when we install BizTalk-SP2, this stored procedure is brought back to default which is empty.

The above are just the few of the issues we faced. And its always advisable to plan properly for restore while installing the BizTalk Server 2004 – Service Pack 2.

Read the following Microsft KB article on issue in BizTalk Server 2004 Service Pack 2 that are not documented in the Readme file:
<<http://support.microsoft.com/kb/940519>>

Debugging is not supported under current trust level settings

When you try to open any web service/web-application from Visual Studio, you may get the following error:

Debugging is not supported under current trust level settings.

The problem is with the trust level setting of your application. Modifying the web.config file of your application would solve this problem:

Solution:
Locate the <system.web> section.
Insert the tag: <trust level="Full" />