I know that in my last post, I said I was revitalizing a previous blog post by Thomas Canter. However, last week, while I was sitting in my car and waiting for my wife to finish her swim, I received an email with a simple question: Are you interested in more old blogs?
My answer was immediate—hell yes.
So here we go. This is another classic post by Thomas Canter that is still surprisingly relevant today: The New VirtualStream in BizTalk Server 2006.
📝 One-Minute Brief
A revisit of an old but still relevant BizTalk Server feature: VirtualStream. This article explains how VirtualStream works, why it still matters today, and which security and performance considerations you must address when processing large messages.
The New VirtualStream
I bet you are all drooling over the new VirtualStream support in BizTalk Server 2006 (once again, this applies to any version of BizTalk Server, including 2020). With this, you can access a forward-only read stream as if it were a fully implemented stream with both forward and backward access to the data.
The VirtualStream is implemented via undocumented APIs but is also exposed in the SDK as VirtualStream.cs, so I feel pretty safe using the deployed version.
But the use of the VirtualStream is not what this is about. This is about the security implications of the VirtualStream. The VS supports a disk caching scheme to store large streams…
As such, this means that the stream size in the cache can be quite large, and you _generally_ don’t have to worry about it, but in fact, you do because this can fail subtly and unexpectedly.
Two things can go wrong in this scenario.
Understand that the stream is cached to the BizTalk Server Host Instance account’s %TEMP% folder, generally under:
- C:\Documents and Settings\<BTSHostInstanceName>\Local Settings\Temp
The first problem I see here is that the C: drive is NOT a good place to put large files that grow unexpectedly. The IO performance is poor, and, in addition, you could unexpectedly exhaust the drive space. So, I recommend manually setting the BizTalk Host Instance’s TEMP folder to a separate drive, preferably a non-backed-up high-speed disk.
Ok, so now you have the TEMP folder set to a separate drive, the second problem that could occur is that the BizTalk Host Instance account may not have Read-Write access to that folder. When the account is logged on for the first time, the OS builds the account’s local folder structure and gives it the correct access, but you need to manually set this when you manually set the TEMP folder location.
So:
- Try to move the TEMP folder of the BizTalk Host Instance account to a large, non-OS-used drive.
- Make sure that the BizTalk Host Instance account has full control of the folder.
That’s it! Then you won’t get surprising failures in your pipeline when processing large files.
Thanks, Tom, for sending me this interesting stuff!
Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more, you can buy (or help buy) my son a Star Wars Lego set!
