It's going around and a bit like a 'who dunnit' (sort of). In short - someone 'tags' you and you then have to reveal 5 things about yourself you normally wouldn't.

VSTS Guru Anthony Borton did me the honours and now I'm tagged. (thanks!)

So here goes:
1. I won $300 dollars when I was 15 on a radio competition for the longest toe(5.5cms) in Wollongong (where I grew up) - the comp. was on for the day and you had to go into the radio station for them to measure. My record stood from 10.30am onwards.

2. During my school holidays I used to sell Watermellons on Bondi beach in the mornings - had something going there.....

3. When I was 7 my dad dressed me up as a girl with a wig (we have a womens fashion shop in the family) etc. and took my sister and I to the local circus - as girls got in for free. (My therapist says I'm doing well now and nearly over it)

4. I'm left handed - "left handers are the only ones in their right mind" (something like that - I had a t-shirt when I was 5 with this. Yes using right handed scissors all your life is tough)

5. For my very last exam at Uni I studied for nearly 4 weeks for this last exam. Rode my push bike into the exam - panicked as the exam room was locked and no one else was there. I was 1hr early!! Got into the exam and during reading time didnt recognise one question (it was going to be tough I thought).

I discussed the exam with one of the supervisors only to be told that my lecturer in this subject stream DIDNT HAVE FINAL EXAMS!! We were assessed during the term.........I was back riding my bike again at 9.30am!

Now which island did my friends go to....

My five people I've decided to tag

1. David McGhee - great guy now with Microsoft with a passion for just about anything.
2. Chris Vidotto - Microsoft Technical Specialist - BizTalk. He's whooping me on xbox live at the moment.
3. Mark Daunt - fellow BizTalk/MOSS/SQL expert - found sleeping in some bizzar places.
4. Clayton James - Loving Sharepoint and being a MCT
5. Mark Burch - Biztalk Support Engineer, and co-founder of the Sydney BizTalk User Group.

Looking forward in seeing what you've got folks.

All full up, eaten several families out of house and home and we all slept under the tree waiting for Santa...early mornings.....:|

Best wishes and see you all in 2007 for an even better year!

Making some headway with this issue I'm experiencing.

I can now go into the BizTalk Application and configure most of the resources found within the Application. I've ventured into Microsoft.BizTalk.ApplicationDeployment.Engine.dll (found in the GAC) and was able to enumerate all the resources etc.

The only thing I havent been able to do is 'an update' to the resource properties (metadata).
I can re-add the resource and overwrite the existing ones, this time with the correct settings, but the problem here is that resources that have dependenies fail. e.g. schemas, maps....

For better of for worse right now I've located the two tables in the BizTalkMgmtDB and modified those directly - all looks good.

The interesting thing is I used %BTAD_InstallDir% extensively throughout the DestinationLocation.

Setting that at deploy time use:
msiexec /i <package.msi> /quiet /log <logfile> TARGETDIR=<your location>

Somewhere within the MSI Installer component within the Package - TARGETDIR=%BTAD_InstallDir%
(Even though all the documentation talks about %BTAD_InstallDir% being an environment variable)

using System;

class MyClassy<T, U>
    where T : class
    where U : struct
{
}

The where clause is used to specify constraints on the types that can be used as arguments for a type parameter defined in a generic declaration. For example, you can declare a generic class, MyGenericClass, such that the type parameter T implements the IComparable<T> interface:

public class MyGenericClass<T> where T:IComparable { }

I recently came across an interesting page - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS06CoreDocs/html/ea7038dc-4740-4c0a-b6a1-08bc22f42bc2.asp

That talks about what is allowed/not-allowed when consuming (and ultimately exposing) WebServices for use with BizTalk.

A handy reference - the interesting one is the 'Any' element not being allowed.
I suppose the alternative is to look at the BizTalk generated WSDL for WebServices that expose messages of Type XmlDocument and see what is in the actual WSDL.

Have fun - 6 more sleeps till Christmas!

Yay!

Usually when referencing an external website we use http://...... and we lose all the security etc. information that comes back from our crawls. (In contrast to the File://c:/docs/... etc etc)

A handy tip you can do is IF you know the site is a sharepoint site you can use the SPS moniker so the indexing service uses the Sharepoint APIs to contact the site as opposed to the http:// protocol handler.
(1) for SPS v2 use SPS://.....
(2) for SPS v3 use SPS3://....

Enjoy.

When I was onsite recently doing a sharepoint migration to MOSS 2007 from WSS V3 - for whatever reason all the servers (and databases) were blown away and all the client had was one content database of their site.

(Who said client sites werent exciting)

My solution here:
(1) install and configure the farm independent of the original content database
(2) Setup the the Shared Services for the Farm
(3) Extend 1 virtual server and create a new content database.
Here's the trick....
(4) From 'Application Management'->'Content Databases'....add another ContentDB
(5) Now select the original ContentDB as an additional one to add. At this point when you click 'OK' there should be two in the list
(I had to actually drop to the command line as this content database addition was going to take more time than the webinterface allowed.
stsadm -o addcontentdb -databasefile:..... -databaserver:..... -url:......)
(6) From the list of two Content Databases - take the non-original ContentDB offline and then remove it.
Viola! Worked a treak...I had to sort out a couple of things around links etc.

(I did try a few other techniques first and got a whole bunch of errors around 'object not in the correct state')

Cheers,

Mick.

On the whole - BTSTask.exe is a great improvement over BTSDeploy.exe in 2004.
A couple of things I wouldnt mind seeing in this tool - the ability to start/stop deployed applications.

Big Gotcha
Something I came across after my large scripting effort.....it goes something like this....
(1) 3 biztalk applications - a 'Core' and Two others.
(2) For the 'Core' apart from Schemas, Maps, Pipelines + Orchestrations; I had 1 COM Assembly, 2 custom adapters, 4 custom functoids and 3 custom pipeline components

So a reasonable sized deployment that needed to easily be deployed into test/production.

My line of thinking was - "If I could get all the associated *.dlls deployed into the BTS Core Application wthin Development...all would be good."
So as we know we can go through the BTS Admin Console and add resources/files/bindings etc. to our application (with various options), that way when we say "Export to MSI..." it's self contained.

The PROBLEM is in the 'Destination Location'....
Using the BTSTask AddResource..... setting the '-Destination:' parameter works a treat (IF your destination location exists within development environment!)

Let me ellaborate....
Development:
e:\projects\<project name>\BizTalk\
     - maps
     - schemas etc....
Associated *.dlls - found e:\projects\<project name>\CommonBin\Release

Testing/Production:
d:\Applications\<project name>\CommonBin...etc. etc.

So the drives are different and what's more, there is NO d-drive in Development....hmmm....I thought.

(I didnt have a 'demo' project to highlight this....so I've removed company info from below)

Where I want to focus is the 'Destination Location'

These 4 assemblies are deployed using VS.NET 2005 straight from the developers desktop.
(When using BTSTask AddResource....-Destination:<loc>   - loc has to exist at time of adding and 'exporting MSI' - bts validates)

Export to MSI...fine MSI finally created.

Installing the MSI file in Production/Testing
Upon performing MSIEXEC /quiet /i Core.MSI FOLDER=d:\Applications\<Project Name>\CommonBin\
I ended up getting a 'msi package deployment' - a guid as a foldername with *.CAB files underneath. No *.dlls etc to be seen.

Importing Into BizTalk
Went to BTS Admin Console and did ImportApp - all looked good.

Then went to the D-Drive and found no new files?? where were my biztalk files? gac-ed files etc?

The ones that needed Gac-ing - found copied to the GAC
The BizTalk ones Schemas, Maps etc - found in E:\projects\<project name>\<development project path>\Bin\Deployment\.....smooth! :-(

As far as I can tell this is attributed to the already existing 'destination location' within the MSI on the BizTalk artifacts.

So the reason why it's soooooo close is that if we could override this (i.e. the above FOLDER= parameter takes effect) then all would be sweet in going from environment to environment.

As it stands at the moment, I'm deploying all the files to Testing building the MSIs there and then deploying to Production with all the correct paths hopefully.

Thought I'd save you some tears.

Buried deep down in one of the Install Guides (multiserver, pg 23) I came across a section that shows you where to change the BAM alert email formats.

Basically there are two files - emailNotification.xslt and fileNotification.xslt both found in the ...\Microsoft BizTalk Server 2006\Tracking directory.

If you want to split the function of BAM alerting to different machines (the Provider, Generator and Distributor within the Notification Services) then there's a little step you need to do, to tell the BAM Alerting Event Provider where these new XSLT files are.

Within the Tracking Dir:

1. Run ProcessBAMNsFiles.vbs - this creates a *.adf file.
2. Edit the *.adf file to point to the new names/location of your modified *.xslt files.
3. ReRun ProcessBAMNsFiles.vbs so it picks up the modified *.adf file and makes the changes to the BizTalk Runtime.
4. Restart the BAMAlerts Windows Service.

Handy one - especially being able to modify those emails.

From students one of my most asked questions about MOSS is...."Will it handle an upgrade?"...something along the lines of .."...you know we have a medium installation of 183 distributed V2 sites with central portals, index propagation and search."

So I thought I'd outline some of my initial upgrade experiences from MOSS RTM.
(On this install - used by a small-medium sized company, they were up for technology so we had SPS2003+SP2...->MOSS Beta2 installed for a while. The RTM install wouldnt kick off until I removed Beta2)

After the product key in the setup I got these upgrade screens....(once the product is installed we can always run the psconfig.exe to start the 'wizard')

I'm doing all at once here - as this company is pretty standard in that fashion. Customisation here weigh in at about 10% of the overall Sharepoint site functionality.

Here's the screen for the File Locations - I moved these out to D-Drive (separate disk) and all the Indexing will be hit pretty hard.
Rule of thumb is to allow 200% space increase for the indexed content. So if you're indexing 100MB, then 200MB free for indexing is recommended.
Actually the search/index process in MOSS is pretty well defined and taking its roots from 'Indexing Service' many many moons ago. The indexes (known as Catalogs - you can access these through the APIs etc) are stored in a highly optimised format. Compressed! And the process of 'indexing' content can be 'tweaked' through things like 'the number of Word lists' in memory, Shadow Indexing and finally the master Index.

Some one was smiling....:)

So at this point I have all the binaries installed and all the appropriate files registered.
The Wizard will go and (hopefully) create the first Admin Site, which from there I can provision the actual Content based sites and the Shared Services (search, excel, mysite etc)

(damn...got hit with a 'we need to reboot to continue...' - so rebooting now.)