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]  

I am preparing to speak next week down in Los Angeles at a user group and am upgrading my demo image from TFS Beta 2 to TFS Beta 3.  After the initial install I couldn't seem to create a project and project creation was taking 20 minutes or more.  On a whim I decided to up the memory on my VM from 512MB to 1GB.  Voila!  I could now create a project and it only took 3-4 minutes.  Big, big difference.

Don't know if this will solve everyone's problem creating projects but it did mine.

Thursday, October 27, 2005 9:09:29 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

I have been an ATTWireless / Cingular Wireless customer now for almost ten years.  They definitely have pulled some bone headed moves in the past but the latest might actually push me to switch carriers.  What is the issue you ask?  Well it is really two fold.

1.  I was an early user of the ATT Wireless Edge and UMTS service.  They continued to work with Cingular until this month when Cingular mentioned that UMTS coverage in Seattle during September would be spotty at best and credited my account the charges for the month of September.  I figured fine.  I will use EDGE in the meantime.

2.  I got a new laptop and had to re-install the software for my PC EDGE/UMTS PC Cards.  I didn't have the old stuff anymore so I grabbed the latest Cingular Communications manager after spending a good hour searching for it on www.cingular.com. Everything appeared to be good until I got to PDC.  I needed to quickly create a web site for the Seattle Code Camp coming up in October. I found however I couldn't create a website anymore in Visual Studio.NET 2003.  In fact I couldn't even request an ASP.NET page off my localhost!  I detailed my travails in a previous post.  Today I hit the cingular forums and come to find out they have known about this for the last couple versions of Communications Manager and still haven't fixed it! There isn't even a response from Cingular to the thread!

I must admit I am more partial to Visual Studio.NET 2003 than Cingular EDGE/UMTS service.  Might be time to start looking at the Verizon EV-DO service my friends have been raving about given the deafening silence coming from Cingular about network upgrades, etc.

The frustrating thing is that Cingular has an entire office building right next to the one I am writing this in.  I have no idea what they do there so I am not about to start accosting the random employees smoking outside the entrance!

Wednesday, September 21, 2005 1:18:43 PM (Pacific Standard Time, UTC-08:00)         Comments [3]  

Woohoo!  Code Camp is coming to Seattle. Portland had the first pacific northwest Code Camp back in July.  Now the show is going on the road and we are having one in Seattle.  Save the dates October 22-23 and plan on attending.

More information at http://pacwest.ms/codecamp/sea/1/

Wednesday, September 21, 2005 9:15:40 AM (Pacific Standard Time, UTC-08:00)         Comments [0]