Gosh, I think I am in desparate need for some new empty bookshelves ...

   <-- Click this pic to see a higher resolution for even more details.

...and you havent even seen my other bookshelves containing my other interest, which I wont share for now ...

I am left speechless at this. Really. Simply astounding ...

One cannot run away from understanding infrastructure needs when one is pitching or designing software solutions in the enterprise (which I do a lot of) and it is sometimes strange (in a pleasant way) when the conversation goes like this:

 Please make sure you have failover expertise in your next meeting. I recommend getting Steve to proxy in for William, even though I dont think anyone can impersonate him. At least, I have been able to ascertain that Steven can mirror William quite well and will be able to backup William in the event of a failure 

I remember back in 2005/2006 when I was still touring the APAC circuits such as Sydney (Australia) and Kuala Lumpur (Malaysia) doing training and consulting gigs for customers, partners about Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF, previously - Indigo) and some of the initial Windows Workflow questions came up regarding the use of Parallel Activities. It came as a surprise to many people that parallel activities are not independently asynchronous.

I explained that a WF instance gets only one instance from the runtime. There are reasons for this single-threaded execution model so each activity have to work with this single thread efficiently. There are ways to spin off differents thread when real parallelism activities are reqquired but because documentation was scare at that time, I had some trouble articulating how to do so.

I just read "Multithreaded Parallelism in Windows Workflow Foundation" on MSDN and while it is a definite deep technical article, if you can grok it, you will understand how "MultiThreaded Parallelism" can be done in WF using both the (rather hard-to-use) "Call External Method Activity (CEMA)" and the "Handle External Event Activity (HEMA)". Not only that, the authors (whom actually implemented such a system for their own use) also shared how to pair those 2 activities up using correlation and how to create wrappers aoround them so that it can be reused and therefore "not require talented software developer use of call-external-method and handle-external-event activities along with the CLR thread-pool"

A gem of a read.

If you make your living installing, deploying, managing and operating Microsoft BizTalk Server 2006. I guarantee that you will be excited and be thankful for the availability of the BizTalk Server Operations Guide. So, what's in it ?

 Guidance based on real-world experience. The idea for the guide originated with Microsoft field representatives, partner organizations, and customers who plan, deploy, and maintain BizTalk Server installations. This group of IT professionals has accumulated extensive hands-on experience with a diverse range of BizTalk solutions. As they gained experience they created checklists, best practices, and presentations to guide future BizTalk Server operations. We collected and organized this information to create the guide.
Key portions of this guide are new; however, a considerable portion consists of documentation taken from BizTalk Server 2006 R2 Help, white papers, Knowledge Base articles, and other sources. It has been carefully reviewed and vetted by experts from the community of BizTalk Server IT professionals and members of the product development team, whom we gratefully acknowledge at the end of this topic. We believe that the information presented here will help BizTalk Server users solve, and above all, avoid many of the common problems that can occur while deploying and maintaining a BizTalk Server installation.

Enjoy.

The BizTalk Server Operations guide is now available for download in DOCX, CHM, and PDF file formats.

Problem: If you are in the configuration screen of Microsoft BizTalk Server 2006 and you are configuring Business Activity Monitoring (BAM) Portal, you checked 'Enable BAM Portal" and you noticed that the Account and Windows Group options are still grayed out.

Cause: I suspect that if you have configured BAM Portal once from any server in the BizTalk Server group, the user account fields are disabled on the rest of the servers even though Enable BAM Portal option is still available.

Resolution: Reset BAMVRoot in the BAM config file: BAMConfig.xml and then run BM update-config

Used bm.exe to get the BAM configuration XML:

1. Open a command window
2. Go to C:\Program Files\Microsoft BizTalk Server 2006\Tracking
3. Type: bm.exe get-config -FileName:BAMConfig.xml

It specifies BAMVRoot so it appears someone configured BAMPortal before. Deleted this line:

1. <GlobalProperty Name="BAMVRoot">http://FOOBAR:80/BAM</GlobalProperty>

Saved the file and updated the BAM configuration:

1. Open a command window
2. Go to C:\Program Files\Microsoft BizTalk Server 2006\Tracking
3. Type: bm.exe update-config -FileName:NewBAMConfig.xml

The options will no longer grayed out. You will probably get an error that the "BAMAppPool already exists". That is fine. Delete it, restarted IIS and it will be configured successfully.

As far as I can tell - this is not documentated very widely and this has helped me so I hope it helps someone out there as well.

Microsoft Office SharePoint Server (MOSS) has seen tremendous take-up rates, not just here in Singapore, but all over the world. I came across many kinds of architectural topology designs during field work with my customers.

One of the most common confusions I have come across arises from the topology design when it comes to the deployment of the MOSS Farms. Some people advocate that the Index server be placed in the same box as the Web-Front-End (WFE) servers with the view that idle power is wasted resources.

There is logic behind this:- Indexing/Crawling not just takes up processing power, it places a certain load on bandwidth as well. The typical organization will set it to crawl at night when online transactions are fairly low. Of course, this is very subjective and differs from environments to environments. A huge load doesnt mean just crawling thousands of websites and fileshares but sets it at a very frequent and short period for incremental crawling. Most of my customers set it to crawl 2-3 times a day (morning, lunch-time, wee-hours at night). That is really not a huge load.

If those are your requirements, you may think having a dediated Indexing Server may be an overkill. If you can bulk-up one of the WFE servers on roids (using a combination of RAM and CPUs), that particular WFE may be able to double-up as a Index server. This will save some costs as well as processing power on that one machine that is just expected to work 3 times a day. Mind you, that machine is expected to be of some decent build as well.

An indexing server can neither be load-balanced nor clustered. What most people want is availabilty at the Query servers, not the Index servers. The built indices are propagated to the Query/Search servers.

There are certain things you need to be aware of, especially when it comes to high-availability in your environment. As said in the referenced link, if an Index server doubles up as a Query service as well, it will not propogate its indices to the other Query servers - that is the gotcha. So, if you have already scoped out 2 WFEs (with the Query service ON) and 1 Index server together with a pair of clustered SQL boxes (one of the most common 5-server MOSS setups), you should try to see if you can run WFE on that Index server and turn the Query service of that particular server OFF. If you can successfully do that, you would have a 3 WFE, 2 Query and 1 Index logical server deployment. You should have the best of both worlds this time around. Hardware resources on that Index server will be more efficiently utilized and you can take one of the WFE servers offline and still enjoy redundancy.

Do take note that this is my own personal advice only. No two customers have exactly the same functional and non-functional requirements and a few of the cases I have seen actually run the crawlers on hundreds of sites, thousands of documents and fileshares and build up the indices up to 10 times a day. In those cases, you should have a dedicated Index server and not have any resource processing contention issues with it. Follow the principles to make sure you max out the hardware resources and costs.