Big change for me today.  After 5 years of being independent and running my own company I accepted a position with a local company today.  As of today I am now Chief Architect for Vertafore. I have been working with these guys in a consulting role for the last few years and they for some reason thought it was just an extended job interview! I am excited to continue to work with the great team at Vertafore.

I will likely keep this blog in place but it may move at some point in the future.  Will let everyone know.

Monday, February 13, 2006 2:41:13 PM (Pacific Standard Time, UTC-08:00)         Comments [5]  

I am a big fan of Jamie Cansdale's TestDriven.net.  Today I tried to use it in VS2003 and clicking on the Run Test(s) item did nothing!  I almost panicked.  I couldn't envision going back to nUnit GUI.  I checked all the usual suspects.  Uninstalled, got the latest build of TestDriven.net, reinstalled, reset the packages in VS.NET, read the FAQ on the TestDriven.net site.

Finally I gave up and sent Jamie some mail.  Jamie doesn't know me from Adam. Not only did he respond but he responded within 5 minutes!  Had me use SysInternals excellent DebugView to give him a log of what was going on. Looked like there was an issue using EnvDTE to get the active window in VS2003.  He pointed me at a Craig Skibo article documenting a problem with some uninstalls unregistering components used by Visual Studio AddIns.  Specifically DTE.OLB.

Ran:

Monday, February 13, 2006 2:37:54 PM (Pacific Standard Time, UTC-08:00)         Comments [0]  

We have hit two issues in recent weeks with this. 

1.  ASP.NET Session or Authentication cookies do not work correctly on a server with an underscore in the name. Jon Box reminded me of the issue and Scott Hanselman chimed in. Come to find out this is really an Internet Explorer issue.

2.  SQL Server has issues installing and other random issues on a server with a hyphen in the name.  Note this is primarily a SQL 6.0/6.5 issue.

Tuesday, January 17, 2006 9:08:06 AM (Pacific Standard Time, UTC-08:00)         Comments [1]  

We are getting ready to roll out a product with one of my clients based on Analysis Services 2005. The product is one of their first that requires Active Directory integration.  This is mainly predicated by the fact that for some reason Analysis Services 2005 will only work with Active Directory based authentication.  So we had to create a whole new credential store just for this addin.

As we were doing it we decided that we would create a group for each cube and then add members to the group to grant access to the cube.

This worked great in Development but when we went to deploy it to our QA environment failed.  The users never had access to Analysis Services.  It drove us bonkers trying to figure it out.

After some time on the phone with Microsoft PSS we found the issue to be the fact that we had used a Domain Local Group.  Come to find out these groups are only intended for use on Domain Controllers.  I had neve seen this distinction and must admit I had always wondered the difference between the two group types.

Our development machine was not a domain controller but for some reason the groups worked there. The solution?  Move to Domain Global Groups which will work on any machine in the domain.

Friday, January 13, 2006 10:46:53 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

Anyone else headed to Mix06? 

I must admit I was really debating on this one. 

The promotional materials are very, very slick.  Very black turtleneck to use a phrase from the 90s.

On the other hand the information on the web site was pretty minimal until just this week.  No detailed session descriptions with presenter names, etc.  We have started getting some session information but it feels very preliminary and there is still no information on who is presenting. The conference is only 9 weeks away! It is almost as if they are saying, "Trust us, we sell out TechEd every year."

Well I finally quit waffling and decided to go.  The promise of what they are offering is enough and I do somewhat trust Microsoft after the last couple of PDC events that have turned out quite well.

I am excited Microsoft finally realizing their is code in a web application in places other than just the backend and am hoping we see some interesting new stuff.

The fact that it is in Las Vegas isn't such a bad deal either!

See you in Vegas!

Friday, January 13, 2006 8:06:12 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

I had an issue with Outlook 2003 that after installing Visual Studio Team Suite RTM & Team Foundation Client almost everytime I tried to start outlook it would attempt to run visual studio setup.  It would prompt for a disk, run for awhile and then let me use Outlook.  I thought I was alone until Walt Ritscher mentioned having similar problems. 

I tried everything just short of paving my laptop to get rid of this including uninstall reinstall of Office 2003, Visual Studio 2005, etc.

Finally I found a forum post that mentioned re-registering a Windows Installer dll.

In short: regsvr32 "C:\Program Files\Common Files\Microsoft Shared\MSI Tools\mergemod.dll"

More information is in this MSKB article: http://support.microsoft.com/kb/329214/EN-US/

Thursday, December 22, 2005 10:11:55 AM (Pacific Standard Time, UTC-08:00)         Comments [0]   VSTS

I was interested in exposing our Team Foundation Server Beta 3 Refresh install out over the internet so I could use it from client sites, etc.

It turned out to be more effort than I had hoped.  Figured I would document it for the next time I have to do it.  These instructions are for a dual server install.  A single server install should be a little bit simpler.

Start off by creating two public dns names:

tfs.domain.com

and

tfsreports.domain.com

Publish a web server pointing at your application tier using the tfs.domain.com domain name.  Set the listener up to listen on Port 8080 and authentication should be integrated only.  Don't forget to go back into the properties for the policy and make sure the bridging options are set to forward on Port 8080.  It defaults to Port 80 which hung me up for awhile.  This policy is for the web services.

Publish a web server pointing at your application tier using the tfs.domain.com domain name again.  This time set the listener up on the normal Port 80 with authentication set to integrated only.  This policy is for Windows Sharepoint Services.

Publish a web server pointing at your application tier using the tfs.domain.com domain name again.  This time set the listener up on Port 17012 and authentication should be integrated only.  Don't forget to go back the properties for the policy and make sure the bridging options are set to forward on Port 17012.  NOTE: 17012 may not be the correct port for your installation.  Replace it with whatever port Sharepoint Central Administration is configured to run on.

Publish a web server pointing at your data tier using the tfsreports.domain.com domain name. If you want you can limit the path to /Reports/* and /ReportServer/*.  My understanding is that they are moving reporting services to the application tier for RTM so this step will go away.  Listener is on Port 80 with integrated authentication.

That's it for the ISA Server setup.  The problem is that the configuration database for TFS still has the internal machine names specified for accessing WSS and Reporting Services.  This can be fixed by creating a file containing:

    Reports
    Change
   
     
        ReportsService
        http://tfsreports.domain.com/ReportServer/ReportService.asmx
     
     
        BaseReportsUrl
        http://tfsreports.domain.com/Reports
     
  
        DataSourceServer
        http://tfsreports.domain.com/ReportServer
     
   


    Wss
    Change
   
     
        BaseServerUrl
        http://tfs.domain.com
     
     
        BaseSiteUrl
        http://tfs.domain.com/sites
     
     
        BaseSiteUnc
        \\colfax\sites
     
  
        WssAdminService
        http://tfs.domain.com:17012/_vti_adm/admin.asmx
          
   
 

Replace ATNAME with the name of your application tier server.

Save this file as c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Tools\myreg.xml

Open a command prompt in this location and use TfsReg to import the registration information above like this:

TfsReg myreg.xml dtname

Of course replace dtname with the name of your data tier server.

That's it.  That got it running over the internet for me.

Tuesday, December 20, 2005 4:22:36 PM (Pacific Standard Time, UTC-08:00)         Comments [1]   VSTS

That was the error message that greeted me in a packet trace this morning while trying to troubleshoot why we couldn't connect over HTTP to SQL Server 2005 Analysis Services (64Bit) over HTTP.

Looking around I saw issues with a file c:\Program causing issues but this wasn't it.

Fired up Filemon from SysInternals (love those guys utilities!) and found that it was loading WOW64 to load the AS2005 ISAPI filter.  Don't get me started on how lame it is that AS2005 doesn't integrate with HTTP.SYS to provide XMLA over HTTP support natively instead of using an ISAPI filter.  Never the less it seemed a little odd that it was loading into WOW64.  Started racking my brains for what I had done on the server to date. 

Realized we had installed some ASP.NET code to manage the AS instance.  It had problems running under ASP.NET 2.0 so I had loaded it under ASP.NET 1.1.  Since ASP.NET 1.1 was only 32-Bit I had to set the Enable32bitAppOnWin64 to true.  What I didn't realize when I did this is that this flag controls all worker processes under IIS 6.0.  So all of my worker processes were now loading the 32-Bit worker process in Wow64.  When it tried to load a 64Bit ISAPI extension in the worker process it complained (as it should) that this wasn't a valid Win32 application.

Long story short.  IIS6.0 makes you run either all 64-Bit code or all 32-Bit code.  You cannot mix the two.

Monday, December 05, 2005 1:58:46 PM (Pacific Standard Time, UTC-08:00)         Comments [0]  

A couple folks asked for the source code of what I built during the talk.  Here is the directory I ended up with.  Have fun.

Thursday, December 01, 2005 3:44:53 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

Here is a gotcha I was hit with this week.  Figured I would share in case anyone else hits it.

I have an application that uses a windows forms control hosted in Internet Explorer using an <OBJECT> tag. We have installed CAS policy so that this control can communicate via remoting to our main application which is a locally running executable.  This control references a configuration file using a tag in the page.  In preparation for .NET 2.0 we had placed a <SUPPORTEDRUNTIME> tag into the configuration.  Little beknownst to us IEHost ignores this tag yet does not throw an error when it is encounterd.  We thought we were all set for .NET 2.0.  Then we installed it and everything stopped working.  Seems we missed this little tidbit:

All managed controls hosted by Internet Explorer use the latest version of the common language runtime installed on the computer. This means that in some instances the control may not run against the version it was built. This applies to any security zone, but does not apply to downloaded managed executables.

at MSDN.  When our control was loaded into .NET 2.0 we lost the CAS policy we had installed to make things work and the control failed to even load. 

The fix was to update the .NET 2.0 CAS Policy but there was no way we could automate this since any code we were running in the browser ran under .NET 2.0 which had no policy installed.  Kind of a chicken and an egg thing.

BTW when we first called support they told us the solution was to create an iexplore.exe.config and use the supportedruntime tag there.  I can't even believe they suggested this.  It would basically bind internet explorer no matter what it was loading to version 1.1 of the framework!  I could unwittingly break other peoples applications.  Needless to say I indicated this was a non-starter.

When drilling into why Internet Explorer always loads the latest version of the framework I was told that an executable can only load one version of the framework.  While technically true there are obviously ways around this.  Take a look at how IIS uses the worker process to load multiple framework versions side by side, each in their own worker process.  The Internet Explorer team could have probably come up with similarly clever solutions.  It just wasn't worth the effort I suspect given the size of the feature.  Too bad ClickOnce wasn't expanded to allow automatic policy elevation for <object> hosted controls.  This would have solved our problem nicely.

Looks like we will have to send out an installer to install new policy and we will have to continue to do this each time Microsoft releases a new version of the framework.  Lucky for us they aren't pumping out new versions every couple of months!

Thursday, November 10, 2005 1:54:03 PM (Pacific Standard Time, UTC-08:00)         Comments [1]