I am in the middle of a medium size BI project where we chose Microsoft for ETL with the SSIS component of SQL Server 2005.  For various factors, we decided on Cognos 8 for the Cube and Presentation layers.  As part of the analysis we took in to account things like cost, Gartner, In-House skill sets and so on.  It was a pretty even race for Cognos & MS Performance Point Server (PPS) and we ended up going with Cognos.

Some background information on our Cognos implementation.  It came in-house with a product called Agile.  So since we were licensed, we went with it for basic reporting needs.  Now we're at the point we're we are really looking at BI - time analysis of data, ad hoc analysis, KPIs, and so on.  We made an assumption that we could leverage our existing Cognos skill sets into the world of Cognos 8 BI.  It wasn't a great bet.  We sent some people to training and they took away what most take away from a week long course based on a vendor curriculum (This is not just a Cognos issue, we have a real challenge finding solid training for the Microsoft stuff too).

Now, I was in the same position our Cognos talent was in when I went to work on BizTalk.  I had a strong background in the fundamentals of .Net languages and Web development.  I went off to take the one week training course (much love to Mark Berry at Dunn Training) and came away with a strong set of basic tools.  When I went up against the kind of problems we're hitting in Cognos right now, there was a difference.

Searching for help on Cognos technical issues is really difficult.  There is very little out there in the way of web based community.  And a lot of what you do find refers to Cognos' KB which is protected by password.  I am not sure what the hurdle is to getting the password setup... a call to our account representative and some paperwork.  When you're slugging out a technical issue this is not the best customer experience to have. 

On the other hand, Microsoft's community is unbelievably rich and returns many hits when searching for answers.  BizTalk is a pricy tool and is seldom afforded by those outside of serious enterprise grade businesses – which makes is developer base quite small compared to C#, SQL, ASP.Net, etc.  Never the less, there is a rich and vibrant community of users who post and share tremendous amounts of technical insight and know how.  I have become truly active in my local developer community in the pas couple of years and I see now why Microsoft pours so much effort into these folks.  As a direct result, I typically can solve most of my technical glitches or unknowns with a minimal amount of time on Google or Live Search.

I am not saying Microsoft is perfect.  I have my issues when I call in for Technical Support and deal with some of the first line folks.  I here the same frustrations form my Cognos counterparts.  The nice thing is that there is such a wealth of Microsoft product knowledge living both outside and inside Microsoft, that it’s one of those intangibles that is rarely given due weight in a product study.  It certainly keeps the number of calls I’ve made to Microsoft to a minimum.  As for which is the best product… another time and another blog post. 

Comment:  If anyone ever wants to experience the Microsoft community in full force – go to a local Code Camp.  I’ve never gotten so many professional contacts in one place.  And if there aren’t any near you, call you Microsoft Developer Evangelist and ask nicely for some help.  You’d really be amazed.

We've had a problem with our BizTalk Servers for quite a while.  Receive ports to a particular file server would seem to shutdown almost at random.  After much searching of the internet, there was a consenus to build a port watcher application using BizTalk WMI.  We did this and it worked, ports would stop and the port watcher would kick them in the butt to get them going again.  But this was just a band-aid to a huge sore under the surface.  After almost a year of this, a re-researching of the problem finally gave way to a helpful post and then a solution! 

It turns out that when a BizTalk Server is checking LOTS of directories on the same server, the network BIOS command limit can be reached:

"This issue may occur if the client computer submits simultaneous, long-term requests against a file server that uses the Server Message Block (SMB) protocol. An example of a long-term request is when a client computer uses the FindFirstChangeNotification function to monitor a server share for changes."

"This issue may occur if the MaxCmds registry value setting on the client is less than 50, or the MaxMpxCt registry value setting on the server is less than 50."

So, per the kb article, an increase of the MaxCmds regsitry entry to 500 solves the problem (after a reboot)!  Not a BizTalk problem at all.  The limitation in the Windows 2003 OS designed to throttle its workload (for good reason) was causing the receive location to shutdown.  The error message wasn't very helpful from BizTalk as it really didn't provide a good error code or reason to point to the command limit that was eventually found to be the problem.  Now if I can only figure out why my File Recieve loactions to DFS shares do the same thing!

Just spent a few days writing the build procedures for BizTalk 2006 development PCs.  I created a nice Windows 2K3 base with SQL, Office and Studio all ready for the using.  This was my starting point for the installation of BizTalk 2006.  One of the first steps was to rename the machines and re-SID them with NewSid so we could be good corporate citizens with uniquely ID'd machines.  When it came time to install SharePoint, I chose to do it on a non-default web site and to create unique accounts for the App and Admin app pools.  This would help mirror the eventual production configuration.  Everything seemed to go well and then when the step came to verify the extended SharePoint website - the fun began.

The main issue was that I kep getting 404's when trying to accesss the templatepick.aspx page for the new server.  I kep getting 404's.  I allowed directory browsing and could browse around to my heart's content - all the way up to that file.  Then - 404!!!!  I reviewed the logs and also noted:

"Unable to get the private bytes memory limit for the W3WP process. The ASP.NET cache will be unable to limit its memory use, which may lead to a process restart. Error: 0x80070005".

Very troublesome.  I then reran the install procedure without NewSID and it worked flawlessly.

So.  My solution was to not NewSid.  I did however come accross an article that listed some extenisve steps to make the whole thing work after NewSid does its thing:

http://blogs.interknowlogy.com/billsheldon/archive/2006/05/22/2705.aspx

I recently helped a co-worker solve a problem with SharePoint and user account password expiration.  The SharePoint site in question uses local accounts to give access to SharePoint.  These accounts are only used for SharePoint access and will never have anything to do with Exchange or logging into a desktop.  Company security policy requires 90 day password changes and also for the initial password to be changed immediately.

The problem arises when one of these SharePoint users log in to the site with ‘User Must Change Password at Next Logon’ checked on their local account (or when the password has expired).  The user can successfully enter their id and password, but they aren’t allowed into the site because they must change their password.  Since they are authenticating through IIS to SharePoint, there are no facilities out of the box to notify them of the ‘must change password’ condition.  With a few simple steps, you can provide this functionality to the user.

There is a big CAVEAT EMPTOR here!  These steps will provide a web based password change mechanism to your users.  These steps will also provide a password change mechanism to those who are not your users.  This public password change page exposes you to a DOS attack against your accounts.  If I know the name of one of your accounts, I can go this page and issue multiple bad passwords in an attempt to change the password.  This will trigger an account lockout (assuming you have enabled account lockout) which will prevent the real user from accessing SharePoint.

Ok. To setup the password change feature, you have to do the following:

1. For the SharePoint site, add a new virtual directory to IIS6 (e.g. named "iisadmpwd") and point it to "c"\windows\system32inetsrv\iisadmpwd".  Ensure it has Read and Run Script permissions. Make sure that anonymous access authentication is enabled for the IISADMPWD virtual directory.
   
2. Exclude this directory in the "Managed Paths" section of the SharePoint site.
   
3. Set the PasswordChangeFlags value for the website to 0 in the IIS metabase. To set the PasswordChangeFlags value in the metabase, launch a command prompt and change to the Inetpub\Adminscripts folder. Type the following command:
   
   adsutil.vbs set w3svc/1/PasswordChangeFlags value
   
   where value is one of the following values 
   
   Value Description
   0       Password changing requires SSL. 
   1       Password changing is permitted on non-secure ports. 
   2       Password changing is disabled. 
   4       Advance notification of password expiration is disabled. 
   
   and w3svc/1 is the default Web site, you’ll need to replace the 1 with the id number of the SharePoint site.
   
   The following sample command shows how to change the metabase
   PasswordChangeFlags setting to 0: 
   
   adsutil.vbs set w3svc/1/passwordchangeflags 0
   
4. Next, we need to tell IIS that we want it to pre-notify people when therir password is about to expire.  This is optional.  To do this, we simply make another metabase entry:
   
   adsutil.vbs set w3svc/1/PasswordExpirePreNotifyDays 4
   
   where value is the number of days before expiration they start getting reminded. And w3svc/1 is the default Web site, you’ll need to replace the 1 with the id number of the SharePoint site.

At this point you should be ready to go.  If you have any problems, there is a good Microsoft Knowledge Base article at http://support.microsoft.com/kb/833734/ on troubleshooting.

The password change functionality in IIS uses a number of pages in the IISADMPWD directory.  Here is a brief explanation of which is which:

/iisadmpwd/achg.asp: This page does the actual password change work.

/iisadmpwd/aexp.asp: This page displays the password change form for a user whose password has expired. Make sure that you type the account name in the "domain\username" format.

/iisadmpwd/aexp3.asp: This page displays the password change form when SSL is not used.

/iisadmpwd/anot.asp: This page appears when a user's password expires earlier than the number of days that are specified in the PasswordExpirePreNotifyDays entry.

/iisadmpwd/anot3.asp: This page appears if a user's password expires earlier than the number of days that are specified in the PasswordExpirePreNotifyDays entry when SSL is not used.