Speeding up the BizTalk Administrator MMC

I reached a patience limit when the BizTalk administrator took over 2 minutes from launch to showing me my application resources on my (rather slow) VM. I could not remember this ever taking that much time. Of course, BTA console never was a real fastloader, but this was getting excessive.

When I asked a co-worker to logon to the same machine and try the same actions, I was astonished see him do the same job on the same machine in less than 30 seconds. Clearly it was user, and thus, profile related.

I created a clean profile for myself to test this and was proven right. It took less than 30 seconds to get the app running and the resources loaded.

I then started to replace original content from my old profile and tested until I, again, reached a 2 minute+ loading time. Problem recreated, cause found.

It appears there is a settings file that controls, amongst others, the window and grid layout of the management console. Over time this file has grown in size from a mere 2kb default to over 600kb. Loading this file seemed to take too much resources and caused a delay that went to 2 minutes.

I simply deleted the file and things went back to normal. Here is the guilty party:
Microsoft.BizTalk.Administration.SnapIn.dll.config

You can find it in C:\Documents and Settings\-your account here-\Local Settings\Application Data\Microsoft Corporation\Microsoft BizTalk Server 2006\

Problem: BizTalk makes full backup every 15 minutes

We recently encountered a problem where the BizTalk SQL Agent job that executes the backup procedure resulted in a full backup every run in stead of once every day.

We became aware of the issue when disk space events were fired by our monitoring software.

We found the problem when we looked into the table adm_BackupHistory in de BizTalkMgmtDb. For some reason someone had felt the need to manually execute the backup job and somehow managed to enter a date in the future as the last-run entry.

In stead of february 3rd, march 2nd was entered (European dd-mm-yyyy vs US mm-dd-yyyy mix-up.) A classic by al means.

This caused the backup's job logic to determine if it was time for a full backup to fail and always return true.

Once this part of the history was corrected, the Backup Job went back to normal operation.