Published on Wednesday, 9th July 2008 .
For those of you that still live in the wonderful world of BizTalk 2004 and use the EnlistOrch.vbs script, I noticed today that it will always use the default Host when starting, which is a bit annoying when you have set another host during binding and are scripting your deployment…..
I’ve updated the script to accept the Host you want the orchestration to use as a command-line parameter, this ensures that the orchestration will be started with the correct Host. Invoking the script now looks something like the following (note the new HostName parameter):
C:\>EnlistOrch.vbs <OrchestrationName> <Assembly> <HostName> [Action]
An updated version of the script can be downloaded here.
Published on Tuesday, 8th July 2008 .
Just a quick heads-up for those of you managing a SQL Server environment, it looks as though there is an important update for SQL Server versions 7.0, 2000 & 2005. Full details of bulletin MS08-040 are available on the Microsoft Security Bulletin Website - details are as follows (my emphasis):
This security update resolves four privately disclosed vulnerabilities. The more serious of the vulnerabilities could allow an attacker to run code and to take complete control of an affected system. An authenticated attacker could then install programs; view, change, or delete data; or create new accounts with full administrative rights.
This security update is rated Important for supported releases of SQL Server 7.0, SQL Server 2000, SQL Server 2005, Microsoft Data Engine (MSDE) 1.0, Microsoft SQL Server 2000 Desktop Engine (MSDE 2000), Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Desktop Engine (WMSDE), and Windows Internal Database (WYukon).
The security update addresses the vulnerabilities by modifying the way that SQL Server manages page reuse, allocating more memory for the convert function, validating on-disk files before loading them, and validating insert statements.
The hotfix will be installed automatically by Windows Update (as it has just done on my development machine); you may want to check it on a non-production environment first to ensure there are no unwanted side affects.
Published on Tuesday, 1st July 2008 .
The BizTalk 2006 Message Archiving Component I released in March of this year on Codeplex has been received well by the BizTalk Community based on the e-mails I have received and downloads (156 source code downloads & 51 binary downloads):
The component allows messages to be written to the file system for archiving, it can be executed in either the Decode (Receive) or Encode (Send) stages and uses message context-properties to define the archive path. The component is written in a streaming fashion, is designed for large message consumption and can handle Xml, binary and flat-files. If you haven’t tried it yet, download a copy from Codeplex now.
I’m now starting to think about feature enhancements for the next version, 0.4; my current feature list is as follows:
- Enabled/Disabled flag to allow easy on/off functionality at run-time
- Archiving to database (rather than file)
- Enhanced logging functionality
- ‘Special’ macros to include values other than those taken from the context properties (e.g. %ReceivedFolderName% when messages are received via the file adapter)
- MSI-based installer
- Documentation!
Please feel free to add any further features or requests via the comments.
Published on Monday, 30th June 2008 .
Yet more great content over on the (RedGate sponsored) Simple Talk blog, this time an excellent article on tracking down deadlocks using SQL Profiler by Brad McGhee, well worth a read before your production system starts to exhibit this behaviour!
Published on Friday, 27th June 2008 .
When we make changes to our BizTalk environments, we always ensure that the changes are scripted so the Ops Team don’t really need worry about messing things up - as a result, we use Binding files everywhere. Normally, we do large scale solution deployments, but earlier this week we needed to update the subscription filter on a single Send Port; to my surprise, I was pleased to discover that Binding files can be used to update existing (unenlisted) Send Ports - no need to delete and re-create (via the binding file).
Consider the scenario above, we have a Send Port subscribing to messages where the Receive Port Name = ‘Sample Receive Port’:
To update the subscription using a bindings file, strip the Bindings file down to just the Send Port in question and update the <filters> element to include a new subscription (a filter on BTS.InboundTransportType has been added in this case, the operator of zero indicates that its an equals predicate):
With the Send Port in the unenlisted state, import the updated bindings file either BizTalk Admin Console or BTSTask and the filter conditions on the Send Port will be updated:
Enlist and start the Send Port!
Note that any configuration property on a Send Port can be updated in this way.