January 2009 Entries

When this dreaded error crops up, its usually right in the midst of a fast and furious development effort. That's always been the case for me! To solve it in a hurry, I just dub the app with a higher version number, recompile and move on--at least that is what I did when I was a bts developer. Now that I'm a bts admin, I've delved into the topic more. Although the re-versioning scenario works, it is possible to re-deploy an *.msi package with the same version number using these few steps:

  1. Go to \Documents and Settings\[deployment acct username]\Application Data\Microsoft\BizTalk Server\Deployment\BindingFiles. (READ: you should see 2 on a reploy, one with a tilda [~]; 1 without)
  2. Since a new app with a new version # creates a BindingInfo xml file on an initial deployment, rename the one you find there to something else. Get rid of the new one (file without the ~) that failed.
  3. Import/re-deploy the *.msi file again.

Why do these steps  work? It appears that new app deployments create the Binding.Info.xml file based on the initial assembly reflection which has the orchestrations, etc.  -- however -- when you redeploy an existing app, the binding file gets generated based on the details stored in the bts management database (BizTalkMgmt)  for that  existing assembly. The  binding file that gets generated from that process is the one  without the ~. 

When you get rid of the base/initial bindings file, bts does not try to apply the bindings it expects to find  (even if there aren't any)  like it does the first time it recognizes the file.

These steps should solve the "ghost" bindings issue, but if not for some reason, there's always the tried and true re-versioning of the app!! 

 

 

 

Perhaps you've experienced the scenario where you hit the F5 key on the Group Overview in the BizTalk Admin console and instead of seeing your message queues, you see instead the very ugly () message: 

Failed to create a CLSID_BizTalkPropertyBagFactory COM component installed
with a BizTalk server. A dynamic link library (DLL) initialization routine
failed. (WinMgmt)

Go to the event viewer and look for any COM/COM+ errors under applications. Chances are you will see a conflict with WMI services--perhaps a threading error. Since the SSO, BizTalk Admin Console, SCOM...(even event viewer) use WMI for the MMC console, one of the DLLs for WMI may have become unavailable. If WMI is not available, or the WMI service has crashed,  the console for the BizTalk Admin  can fail with this error message as its swan song ().

Aaron Tiensivu's blog offers a way to isolate WMI issues on svchost:

http://blog.tiensivu.com/aaron/archives/294-Suspect-that-WMI-is-crashing-your-SVCHOST-Run-it-standalone..html

There are 2 solutions that I know of, 1 radical and 1 less so...

  1. restart the server [waaay radical, but effective]
  2. restart the WMI windows service

 

 

 

 

The full error message looks like this:

[SNAC] “[SQL Native Client]SQL Network Interfaces: The Local Security Authority cannot be contacted.[SQL Native Client]Cannot generate SSPI context”
[MDAC] “Cannot generate SSPI context”;
[.Net1.0/2.0]” Failed System.Data.SqlClient.SqlException: Cannot generate SSPI context”

When this message occurs--especially when the same access 20 minutes ago worked, chances are you've logged off of your primary network. An example would be that at work you were using an ODBC connection to reverse engineer a database into a Visio diagram on a local MSSQL Express instance, then when you went to work on it after hours at home offline the connection fails with this error message.

In essence, your desktop/laptop with the local db  instance is disconnected from its domain.  The immediate solution in this case would be to VPN back into the network and keep moving forward!

There are other causes, and there are workarounds to the disconnected network roadblock that are explained exceptionally well in this MSDN blog:

http://blogs.msdn.com/sql_protocols/archive/2005/10/19/482782.aspx

Yes! .....(Now, we're not talking about bulk inserts--which is a completely different task... we're just talking about a small number of rows that need to get inserted into a relatively static table)..

Typically folks do something like this to quickly add rows into a reference  table:

INSERT INTO ReasonType
(DisplayName,Description)
VALUES
('Delay','Reason for a project delay')
GO
INSERT into ReasonType
(DisplayName,Description)
VALUES
('Cancellation','Reaon for a project cancellation')
GO

...but it is possible to do this instead...

INSERT INTO ReasonType  (DisplayName, Description)
    SELECT  'Delay' ,'Reason for project delay'
    UNION ALL
SELECT  'Cancellation' ,'Reason for project cancellation'
    UNION ALL