Oops, an update to my last post about redirecting OWA users when deploying Exchange with ISA. Here is a blog detailing the "correct" way to do it, and also how to redirect http to https, etc.
Monday, March 31, 2008
In setting up Exchange 2007 OWA through ISA Server 2006, I realized that it would be a lot easier to tell users to access it via http://owa.domain.com as opposed to http://owa.domain.com/owa (which is repetitive if nothing else).
Problem is, there is no obvious way to do this in ISA or Exchange. Fortunately I am not the first one to have this problem, and it has already been solved. The short version of the fix is to set OWA up 100% according to whatever book, article, white paper you are already following. THEN, add another web access rule point to the same site, except this time set it to Deny. You don't have to get too fancy on the various settings, authentication, etc. and just use the same listener that you created for OWA.
Once the rule is created, make sure it is the one just above the main OWA access rule (I named the new one "Redirect OWA" so I would know what it was), and then go back in and on the deny page, set it to Redirect to your specific OWA subdirectory (http://owa.domain.com/owa). It works great!
Here are the two resources that I found to be most helpful:
Blog du Tristank (look in the comments)
**UPDATE** I have since found a blog that tells the correct way to do this (but the quick and dirty listed above still works fine). Here is a link to my blog post about the correct way.
Thursday, March 20, 2008
If you want to spend some time tuning performance of your SSIS solution, it is likely that at some point you will leverage the SSIS performance counters found in the SQL Server:SSIS Pipeline object. However, if you are using 64-bit SQL, you will not find the performance counters listed in PerfMon. That is because here is a known bug in SQL Server 2005 x64, which you can read about in KB 941154.
What is the problem? The short version is: When SQL is installed, it accidentally points to the \Program Files (x86)\ directory for the SSIS PerfMon counters, except that they are actually in the \Program Files\ directory.
How do I fix this? Its easy, but requires a reboot. Here are the instructions, straight from the KB linked above:
To work around this problem, follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate the following registry entry:
3.Double-click the Library registry entry.
4.In the Edit String dialog box, type the following string value in the Value data box:
DriveLetter:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTSPipelinePerf.dll
5.Restart the computer.
UPDATE: This fix does not work as described in the KB
Even though there is a DTSPipelinePerf.dll file at the path given in KB 941154, simply pointing to it in the registry setting and rebooting does not make it visible. I was able to get it to work using Plan B: change the path back to \Program Files (x86)\ and use the 32-bit version of PerfMon.
There are two ways to use the 32-bit version of PerfMon:
1.) Start | Run | mmc.exe /32 perfmon.msc
2.) Execute c:\windows\sysWow64\Perfmon.exe
Monday, March 17, 2008
For a good summary of many different ways to run an SSIS package programmatically, as well as advantages and drawbacks of each, look here at Michael Entin's blog. There are some good things in the comments as well. This will come in handy at some point, I am sure.
Monday, March 10, 2008
Wednesday, March 5, 2008
I am an avid user of Alberto Ferrari's SQL Server Integration Services "Table Diff" component, which you can download from http://www.sqlbi.eu. He recently released the new, improved version 2.0 of the component (the .dll still says that it is 1.0 though?) and I am upgrading a mid-size solution that makes heavy use of the prior version of TableDiff (1.x) to use the new component. Here are my observations of both the upgrade and the new capabilities of the component.
Here is a typical Type 1 style update package (in this case an import table, not a dimension) that uses TableDifference at its core to compare the new and old data flows and direct output accordingly. Behind the scenes, I overwrote the TableDifference.dll file with the new one in both the .NET Assembly Cache and the \PipelineComponents directory. When I opened the package, everything is working except the Update and Insert components have red X's. These are easily fixed by simply double-clicking on each to open properties, accepting the new automatically matched column references and saving the package. That's it, there is nothing else required to update your pacakages from TableDifference 1.x to the newly released 2.0.
Tuesday, March 4, 2008
A couple of things about upgrading from Team Foundation Server 2005 to 2008 that I wanted to highlight:
1.) The new version of TFS Explorer does not work with VS 2005. However, you can use the TFS 2005 Explorer to connect to TFS 2008 Server and do 95% of what you need to do. Just install the VS 2008 version on at least one machine to get the extra features if needed, and it will work fine in a side-by-side deployment. If you want the TFS 2008 Explorer, you can download the stand-alone install here.
2.) If you are not doing an in-place upgrade and want to move your source code items and work items (with history), there is a tool on Codeplex that will let you do that (even between TFS 2005 and TFS 2008). You can find it here.
3.) You can download TFS Web Access for 2008 and it presents a very nice UI for interacting with TFS. The Visual Studio interaction is still a little scattered in my opinion.
4.) If you were using Changeset Comments in 2005, you will need to add the TFS 2008 Powertools to get that feature back.
5.) You MIGHT have a problem with adding items to 2008 if you already had 2005 on the same dev machine. I was having problems with phantom workspaces after I deleted them, connections to the 2005 server that wouldn't disappear no matter how many times I deleted them, Can Not Connect To Server errors when I tried to add items to the new 2008 server, etc. HERE IS THE BRUTE FORCE ANSWER: run devenv.exe /resetuserdata and everything will work. *Warning* Your personal Visual Studio settings will be erased if you do this, but that is not the worst thing in the world.