Pythian Group

Installing a 32-bit version of SQL Server 2005 Reporting Services on a Windows Server 2003 64-bit could be a bit of a challenge, as it requires IIS. I have seen several customers who purchased servers with Windows Server 2003 64-bit pre-loaded while they only have a license for a 32-bit SQL Server 2005.

It is always recommended to have a 64-bit application running on a 64-bit OS to take full advantage of the 64-bit platform. IIS, by default, runs 64-bit on a 64-bit Windows Server system. SQL Server Reporting Services requires ASP.NET which can be manually installed on top of IIS.

When you install the .NET Framework on a 64-bit machine, you have both the 32- and 64-bit versions. Nonetheless, you will not be able to install ASP.NET 32-bit version on a 64-bit IIS, which will be needed by SQL Server Reporting Services.

To be able to install ASP.NET 32-bit on a 64-bit IIS, Read the rest of this entry . . .

Most people think Windows administrators make a living with their right-hand—you know, right-clicking and left-clicking the user interface to get things done. While anybody can do that in Windows, the real value comes in when you no longer need to rely so much on the user interface but instead write scripts. Lower total cost of ownership is achieved when the administrative costs are kept low, and this is where Windows PowerShell comes in.

I’ve spent a fair amount of time writing VBScript scripts to administer Windows servers and workstations and automating repetitive tasks. One reason for me moving into Windows PowerShell is its roots in the Microsoft .NET Framework, as I have done a fair amount of .NET programming. But what is Windows PowerShell anyway?

Windows PowerShell is an extensible command-line shell and an associated scripting language built on top of the .NET Framework v2.0. It was released in 2006 and is currently available for Windows XP SP2/SP3, Windows Server 2003, Windows Vista, and is included in Windows Server 2008.

PowerShell will be included as a common engineering criteria (CEC) in future releases of Microsoft server products, making it a must-learn for Microsoft server administrators.

Administrators (DBAs included) have been using scripting to automate administrative tasks with scripting languages like DOS batch, VBScript, Perl, and a few third-party tools like KiXtart and WinScript. Windows PowerShell complements the administrators’ existing scripting toolkit to easily manage and administer Windows workstations and servers and other Microsoft server products as THEY are being built using the .NET Framework.

Although it is designed for operating systems, Windows PowerShell can be used to administer SQL Server 2005 instances and higher, as Server Management Objects—the object model used to manage SQL Server 2005—are built using the .NET Framework, thus exposing the object model in PowerShell. And since SMO is compatible with SQL Server 2000, you can administer SQL Server 2000 instances using Windows PowerShell. SQL Server 2008 even ships with its own PowerShell snap-in.

No wonder it makes sense to learn a thing or two about Windows PowerShell. Besides, I’ve seen Windows administrators being “forced” to do SQL Server DBA tasks even without knowing what T-SQL is. Windows PowerShell makes it a level playing field.

I will be posting a series of blog posts on getting started with Windows PowerShell, and how any Windows administrator can use it for their day-to-day tasks. In the process, I’ll also cover how to use Windows PowerShell for administering SQL Server instances.

In Part 1 of this series, we prepared our Windows Server 2008 servers to be a part of a cluster. Part 2 showed us how we can add the shared disks, install the Failover Cluster Feature, and run the Validate Cluster Configuration Wizard. In this post, we will complete the process by creating a Windows Server 2008 cluster.

Creating the Windows Server 2008 cluster

Once you have managed to install the Failover Cluster Feature on both nodes, you can run the Failover Cluster Management console on either of the nodes. To do so:

Read the rest of this entry . . .

In Part 1 of this series, we prepared our Windows Server 2008 servers to be a part of a cluster. In this part, we will look at adding the iSCSI disks to the servers. The series of steps outlined below should be done on both nodes.

Before we go any further, I must mention that you should have at least two network cards configured on both of the servers, where one NIC is connected to the local area network, and the other to the other server and is private. This second NIC will be considered your heartbeat, where communication between nodes will travel. This is basic when configuring any cluster nodes. How these cards are configured will come into the picture as we go along in the process.

1. Add the iSCSI Targets as disks on the server nodes

Windows Server 2008 comes with iSCSI Initiator software that enables connection of a Windows host to an external iSCSI storage array using network adapters. This differs from previous versions of Microsoft Windows where you need to download and install this software prior to connecting to an iSCSI storage. You can launch the tool from Administrative Tools and select iSCSI Initiator.

To connect to the iSCSI target: Read the rest of this entry . . .

This happens to be my very first blog post with Pythian, and to kick this thing off, I would like to talk about building a Windows Server 2008 cluster.

As DBAs, we cannot separate ourselves from the grueling task of having to deal with the underlying operating system, especially as new versions come out. Running SQL Server also means understanding the operating system on which it runs. And since Windows Server 2008 has been released for almost a year now, a lot of customers are upgrading from Windows Server 2003 to this new version.

Installing SQL Server on a stand-alone server or member server in the domain is pretty straightforward. Dealing with clustering is a totally different story. The goal of this series of posts is to be able to help DBAs who may be charged with installing SQL Server on a Windows Server 2008 cluster.

The best approach is to always have an environment on which to run these tests. In my case, I run VMware Workstation 6.5 on my Windows XP laptop. Here are the steps that you need to take.

Read the rest of this entry . . .