1. Open the command prompt and find your way to BM.exe (Program Files\BizTalk ...\tracking\)
2. Retrieve the current configuration information:
   bm get-config -FileName:"BAM_Config.xml"
3. Update the config file to remove the reference to the current website:
   <GlobalProperty Name="BAMVRoot">http://blah.blah.remove.this.URL</GlobalProperty>
4. Update the BAM configuration database:
   bm update-config -FileName:"BAM_Config.xml"
5. Re-run the BizTalk Configuration Tool and re-configure the BAM Portal feature and you should be good to go

Conclusion...

Nothing in BizTalk is as it seems

• Create a separate App Pool running as a user that has permission to the BizTalk Isolated Host (I just ran it as my BizTalk Iso service account as a shortcut)
• Make sure this app pool is running as classic mode and not integrated mode
• CHECK THE TRUST LEVEL to make sure it is appropriate ... in my case I just set it to Full Trust to get it through my test
• Don't for get to enable the receive location, it is not enabled by the wizard ... you couldn't imagine how many times I forgot to do this while trying to figure out why my darn service isn't working again!

Well ... hope this helps someone else!

We've all been there...
When you are working with a team of developers (whether two or ten), who are collaborating on a project in Visual Studio.Net, there certainly is the chance that you will need to add a new file to the solution.  Of course, to do this you have to check out the project file locking it for yourself.

Play Nice!
The courteous thing to do (karma, right?) is to add your file and immediately check in the new project file with your newly added file (as long as it doesn't break the build :) ).  Try doing this in BizTalk sometime (if you already haven't) and watch the quick destruction of your file.  Once you start editing that file again and check it back in you get a nice little warning about the encoding type changing.  Visual Source Safe does not handle this very gracefully; Visual Source Safe does not handle this at all.  You will be fooled into thinking your file is safe because you are working with the version on your local disk but the next time one of your team members gets the latest version of your project the file will be toast.

What the ...?
The issue here is that when you create new files in VS.net it likes to create them as UTF-8 encoded files.  Seems like a good idea; a nice standard encoding type.  BizTalk, however, has to be different and save everything as UTF-16.  Once again, another nice, standard format.  However, visual source safe is completely oblivious to the change in encoding types an will gladly assume that your are still managing a UTF-8 encoded file.

The Moral
You can still be a gracious team member and have a quick turn-around on adding new files to the project but just give those files a little edit first before you check everything in.

The keyword new is required on 'Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage' because it hides inherited member 'Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(int, Microsoft.XLANGs.Core.Envelope, Microsoft.XLANGs.BaseTypes.XLANGMessage, Microsoft.XLANGs.Core.Correlation[], Microsoft.XLANGs.Core.Context, Microsoft.XLANGs.Core.Segment)'

'Microsoft.Samples.BizTalk.SendMail.ReceiveSend.ReceivePort' denotes a 'field' where a 'class' was expected

Static member 'Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage' cannot be accessed with an instance reference; qualify it with a type name instead

'Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage' denotes a 'field' where a 'method' was expected