November 3, 2009 by james.

I ran into an interesting issue a couple of weeks ago with Outlook Web Access authentication.  A good friend of mine (who shall remain nameless) called me to get some help getting OWA working properly on Exchange 2007.

 After some testing and questioning, I discovered that they attempted to rename the OWA virtual directory to Exchange without deleting the existing Exchange virtual directory.  Step 1 was to convince them it was easier to get their users to type the new URL than re-purpose the Exchange virtual directory.

 Once we resolved that issue, we started working on getting the OWA virtual directory up and running.  We kept getting a 401 error, which really didn’t make sense since the OWA virtual directory was set in Exchange to employ Forms-Based Authentication.  So in the interest of time, we decided to delete and recreate the OWA virtual directory.  Same error message.

I started digging into IIS Manager, and discovered that the OWA virtual directory was set to Forms-Based Authentication.  So, tried changing it through the GUI to Windows.  It just reset itself back to Forms-Based. 

So I started digging into the web.config file.  Turns out the web.config file had the authentication type set to Forms-Based, and for some reason, the GUI change was not being written to the web.config file.  We edited the web.config file manually to use Windows Authentication, and it started working.

 Right about now, you are probably saying “Huh?”  That’s pretty much what I said too.  Here’s a quick summation of the lessons learned:

1.  With IIS 7 and IIS 7.5, it pretty much doesn’t matter if have a GUI, to do real work, you are going to have to edit text (XML) files. I thought we gave that up when we left DOS, Novell, and Linux/Unix behind, but I was apparently wrong.

2.  For forms-based OWA authentication to work, the virtual directory has to be set to use Windows Authentication.  (That one left me scratching my head for a while….)

3.  It is much easier to accept defaults and retrain users than it is to decide you don’t like Microsoft’s changes and set things up so the users don’t notice as many changes.

 Hope this helps;

James

Posted in Exchange Server, Windows Server, Technology | No Comments »

October 2, 2009 by james.

If you are looking for technology news, tips, or trick, you might want to check out a new blog, Two IT Guys.  One of the “Two” is a long-time Acknowledge IT customer, colleague, and all-around knowledgeable IT guy. 

 Check them out here:  http://twoitguys.blogspot.com

James

Posted in Technology, Blogroll | No Comments »

October 2, 2009 by james.

We’ve heard lots of interest in Sharepoint over the past year, so we are looking for students for Microsoft course 5061, Implementing Sharepoint Server 2007, October 26-28th, 2009. 

 If you are new to Sharepoint Server, or have some experience in Sharepoint Administration but would like additional information or formal training, let us know as soon as possible.  We would like to get the class details confirmed by Friday, October 9th, 2009.

James

Posted in Training, Technology, Company Information | No Comments »

October 2, 2009 by james.

Those of you who have taken my Windows 7 First Look classes know that I am excited about Windows 7 XP Mode, basically a free version of Windows XP SP3 available to people running Windows 7 Business, Enterprise, or Ultimate on computers supporting hardware virtualization.  This Windows XP virtual machine can have older incompatible applications installed in it that show up on our Start Menu just like any other application.

 The release schedule for Windows 7 XP Mode was unknown until today, when Microsoft released that Windows 7 XP Mode (and by necessity the new version of Virtual PC, which is what the XP virtual machine runs in) will be available for download from the Microsoft Download Center on 10/22/2009, the same day as Windows 7 is released to the public.

I haven’t been this excited about an operating system since, well, I can’t remember….

 James

Posted in Windows 7, Technology | 1 Comment »

October 2, 2009 by james.

I’m not sure whether to be excited or disappointed about this book.  The authors (Landrum, McGehee, and Voytek) try to explain SQL Server Reporting Services in a conversational tone, which I find much lighter and easier to read than most technical books. 

As an occasional user of other reporting software and tools, I am starting to learn SQL Server Reporting Services to have another option that a lot of people have already bought with their purchase of SQL Server.  This book helps, but also hurts…. 

 The book succeeds in describing SQL Server 2008 Reporting Services concepts and theory in a format that someone like myself new to Reporting Services can understand.  Unfortunately, a lot of the code examples have issues, and don’t work exactly as described (or they are assuming a level of knowledge I don’t have that means there are other things I should be doing not in the step by step instructions….)

 Overall, not a bad book, but not really a good one either.  Not sure I would spend the 40 bucks on it again.

 James

Posted in Book Review, SQL Server, Technology | No Comments »

July 22, 2009 by james.

Thanks to four very talented and inquisitive developers who were taking my Implementing a Microsoft SQL Server 2005 Database class last week, I was encouraged to delve a little deeper into SQL Server’s TRY-CATCH error handling structure.  (You know who you are, and thank you….)

First implemented in SQL Server 2005, the idea was to introduce structured exception and error handling into SQL Server.  The general idea goes something like this:

BEGIN TRY
      <SQL Statement(s) to attempt data modification go here>
END TRY
BEGIN CATCH
      <SQL Statements for Custom Error Handling Go Here>
END CATCH

If the code contained between the BEGIN TRY and END TRY statements runs successfully, then execution jumps to the next statement after the END CATCH statement.  If the code contained between the BEGIN TRY and END TRY statements produces an error with a severity level greater than 10 that are not fatal to the connection.

If you are familiar with the TRY-CATCH block in other Microsoft languages such as Visual Basic, you are used to seeing execution jump to the code contained in the CATCH block immediately after the error (exception) is thrown.  Unfortunately for consistency’s sake, this is not the case for SQL Server.

In SQL Server 2005 and SQL Server 2008, all code between the BEGIN TRY and END TRY executes before the error states are checked.  This means you can get yourself into trouble if you “assume” that it behaves like the TRY-CATCH block in other languages.  For example:

BEGIN TRY
     BEGIN TRAN
          <SQL Statement(s) to attempt data modification go here>
     COMMIT TRAN
     BEGIN TRAN
          <SQL Statements(s) to attempt a second data modification go here>
     COMMIT TRAN
END TRY
BEGIN CATCH
      <SQL Statements for Custom Error Handling Go Here>
END CATCH

If SQL Server’s TRY-CATCH behaved like Microsoft’s complied languages, then if the first transaction failed, execution would immediately jump to the CATCH block.  However, in SQL Server, both transactions would run, and while a failure of either would cause the CATCH block to execute, you could end up with one transaction committed you did not expect to be committed.

While SQL Server’s version of the TRY-CATCH is restricted to a single batch, it is not restricted to a single transaction.  If you are going to use the TRY-CATCH in SQL Server, you will want to make sure you only have one transaction or logical unit of work in the TRY block.

 Hope you find this useful;

 James

Posted in SQL Server, Technology | 1 Comment »

July 9, 2009 by james.

 It’s not often I give a book rave reviews, but I only have one small nitpicky complaint about the Windows Powershell Scripting Guide.  That is that the title doesn’t truely convey the usefulness of this book for Windows administrators.

A better title, in my humble opinion, would be:  Powershell Scripts That Do Everything In Windows.

 The first two chapters give a nice basic overview of the Powershell environment, its configuration, and basic language elements (flow control, conditionals, etc.).

 After that, all the rest of the book is about scripts to accomplish many of the day to day Windows administration tasks in Powershell.  Need to read event logs, manage your failover cluster, or configure Server Core?  Scripts to accomplish those tasks and many more are in this book.

 If you want or need to script in Windows, you should have this book for the amazing number of scripts the author includes, if nothing else.

 Thanks;

James

Posted in Book Review, Windows 7, Windows Vista, Windows XP, Windows Server, Technology | No Comments »

July 3, 2009 by james.

Well, this book is designed to prepare you for Microsoft Exam 70-238.  In that regard, I give the book a 50% success rate at best.

 While the fundamentals of the book are good, there are a number of content areas on the exam that the book either gives no information about or very limited information.  If you are new to Exchange Server 2007 and want to use this book, it provides a good starting point, but DO NOT RELY ON IT FOR YOUR ENTIRE PREPARATION FOR THE EXAM!!!!

If you do, well, e-mail me and we’ll place a side wager on whether or not you pass your exam.

I could not review the included practice tests on the CD because my CD was defective and would not play on either of my computers.  I also found the Case Scenarios wordy and lacking truly technical questions like those on the exam.  Some of the Suggested Practices for hands-on work were very weak as well.

In summary, if you are new to Exchange Server 2007, this book has some good background information, but it is not a comprehensive review or learning resource for passing your exam.

James

Posted in Book Review, Certification, Exchange Server | No Comments »

June 2, 2009 by james.

We now have a release date for Windows 7, it looks like we’ll see the new product on October 22nd, 2009.

Woo hoo…..

http://blogs.zdnet.com/Bott/?p=1021

Posted in Windows 7, Technology, Blogroll | 1 Comment »

June 1, 2009 by james.

One of the largest pain points for me when Microsoft moved their ETL (Extract, Transform, and Load) technologies for SQL Server from DTS (Data Transformation Services) to SSIS (SQL Server Integration Services) has been their reduced editing functionality for packages saved in the MSDB database.

 As a DBA and not a developer, I have always been a fan of taking advantage of SQL Server’s built-in functionality to protect packages and their “secrets” (passwords for connecting to other systems, etc.) and to ensure that they get backed up along with the SQL Server system databases.  With the advent of SSIS, Microsoft has made this much more difficult to work with since there is no direct editing of packages stored in MSDB.  You end up having to export the package, edit it, and then re-import it into MSDB.  That is a pain in sensitive body parts for more than a couple of packages.

Developers advise us to use the file system to store our SSIS packages like they would store their VB or C# program code, projects, and solutions to work around these issues.  In my opinion, this has some significant disadvantages:

1.  To save secrets in the packages, you have to either encrypt the package with a password or with a user’s key.  If you use a password, that is one more thing to lose or forget, meaning no one has access to the secrets in the package or package source, or everyone does.  If you use a user’s key, then access to the secrets or package source is only available to that particular user.

2.  You cannot take advantage of SQL Server’s built-in roles in the MSDB database like db_ssisadmin to secure who has access to SSIS.  You are forced to rely on a combination of the security listed in Step 1 (user keys and package passwords) and NTFS file system security.  The introduction of having to worry about NTFS-level security adds yet another variable (and in large organizations, another team of administrators) to worry about.

Thankfully, someone has finally taken the time to write and make available an automated way to import packages to and export packages from MSDB.  The June 2009 issue of SQL Server Magazine has a reader solution that allows us to easily import and export SSIS packages from MSDB.  You can find the online version and code here:  http://www.sqlmag.com/Articles/ArticleID/101918/101918.html

Thank you Shaunt Khaldtiance and thank you SQL Server Magazine. 

Hope this helps someone else;

 James

Posted in SQL Server, Technology | No Comments »