server. When asked for the logon we used the id used to log both nodes on the domain (Domain Admin & member of Adminisytrators group on both servers). Got a screen asking for the passwords for the ids for MSSQLSERVER & SQLSERVER AGENT. (screen was not e
xpected).
Environment: Windows 2000 Advanced server active/passive two node cluster. Active node has SQL 2000 SP2 with Security Patch 0655. The new node was successfully added to the cluster. We are trying to push SQL 2000 to the new node. The CD we are using
is SQL2000 Enterprise edition with no service packs. Once we get SQL on the new node and failover to it, we are going to apply SQL 2000 SP3. After that we will start the process of evicting the current node and getting a new Windows 2003 node to join th
e cluster. Once SQL 2000 is on that node and we failover to that node, the node we just added will be upgraded to Windows 2003. We have Q811272 on registry hack when the operating systems of the cluster servers are different and Q 294209 & Q 301600 on m
oving the MSDTC resource from the cluster group to the SQL group.
We would like to know if we are using the correct procedure, if it contains all the steps and we are entering the correct information? Plus what's with the screen asking for the MSSQLSERVER and SQLSERVERAGENT services password.
We would also like to know if the apps using the databases should be down during the install. Can't find that anywhere except for applying service packs.
Ok, You guys are really trying. Major kudos for the detailed post.
Ok, here are my notes.
Computer name = new host name, not virtual servername. The cluster install
already asked for the instance name on a prior screen.
Login info: I prefer to use the SA login, avoiding any NT permissions
issues. assuming your cluster is in mixed mode.
SQL Service packs. Run the SP from the node that owns the SQL group. It
WILL take the server offline while the SP is applied. Get over it. You MUST
apply SP3 or SP3 a before upgrading to Windows 2003.
MSDTC:. Win2000 best practices - put it in the cluster group. Win2003 Best
Practices = make a new group. Practical experiance = I have not seen, nor
heard of a situation where it made a difference.
The real difficulty is going to be making sure that 2003 can access the
shared storage. Drivers are critical.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:0D42B568-1D29-4577-9FA9-327FBF09CC3D@.microsoft.com...
> We can't get SQL 2000 to load on the new node (successfully added to the
cluster). We are using the procedure How to add nodes to an existing
virtual server (Setup)(from BOL). When asked for computer name we entered
the SQL cluster name for the virtual server. When asked for the logon we
used the id used to log both nodes on the domain (Domain Admin & member of
Adminisytrators group on both servers). Got a screen asking for the
passwords for the ids for MSSQLSERVER & SQLSERVER AGENT. (screen was not
expected).
> Environment: Windows 2000 Advanced server active/passive two node
cluster. Active node has SQL 2000 SP2 with Security Patch 0655. The new
node was successfully added to the cluster. We are trying to push SQL 2000
to the new node. The CD we are using is SQL2000 Enterprise edition with no
service packs. Once we get SQL on the new node and failover to it, we are
going to apply SQL 2000 SP3. After that we will start the process of
evicting the current node and getting a new Windows 2003 node to join the
cluster. Once SQL 2000 is on that node and we failover to that node, the
node we just added will be upgraded to Windows 2003. We have Q811272 on
registry hack when the operating systems of the cluster servers are
different and Q 294209 & Q 301600 on moving the MSDTC resource from the
cluster group to the SQL group.
> We would like to know if we are using the correct procedure, if it
contains all the steps and we are entering the correct information? Plus
what's with the screen asking for the MSSQLSERVER and SQLSERVERAGENT
services password.
> We would also like to know if the apps using the databases should be down
during the install. Can't find that anywhere except for applying service
packs.
|||Thanks for the info. NOTE: The questions asked relate to getting SQL on the new node not applying SP3. I figure applying SP3 will be the easist part. And yes I know the apps need to be down and can get a window to do that.
Several questions on getting SQL on the new node:
The Computer Name screen says it wants the name of the "virtual server" there is a later screen (Cluster Management) where we provide the name of the new server. So which of the two virtual server names do we use: the one for the MSCS cluster or the on
e for the SQL cluster? We used the SQL Clsuter name.
The login requested has to have administrator priviledges on both servers which tells me that SA is not the id to use.
What about the screen that showed up that wasn't in the procedure? It asked for the passwords for the ids used for the two services SQL uses.
Do the apps using these databases need to be down when we install SQL on the new node? They can be if needed.
On your comment about the drivers: Our SAN is EMC Symmetrix. The current working node has 2 HBAs & PowerPath (lets computer know the HBAs point to the same disk) the new node has one HBA and no PowerPath plus the nodes have different drivers & firmware
for the HBAs. Based on your comment, I get the feeling that failover won't work. Is this correct? By the way the new node is in the cluster. When we use Disk Management it has an entry for the SAN disk; however, we don't know if it will see the SAN di
sk correctly yet since we can't failover without SQL. Or can we?
Pat Hall
Sr. Database Administrator
pat.hall@.gilbarco.com
-- Geoff N. Hiten wrote: --
Ok, You guys are really trying. Major kudos for the detailed post.
Ok, here are my notes.
Computer name = new host name, not virtual servername. The cluster install
already asked for the instance name on a prior screen.
Login info: I prefer to use the SA login, avoiding any NT permissions
issues. assuming your cluster is in mixed mode.
SQL Service packs. Run the SP from the node that owns the SQL group. It
WILL take the server offline while the SP is applied. Get over it. You MUST
apply SP3 or SP3 a before upgrading to Windows 2003.
MSDTC:. Win2000 best practices - put it in the cluster group. Win2003 Best
Practices = make a new group. Practical experiance = I have not seen, nor
heard of a situation where it made a difference.
The real difficulty is going to be making sure that 2003 can access the
shared storage. Drivers are critical.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:0D42B568-1D29-4577-9FA9-327FBF09CC3D@.microsoft.com...
> We can't get SQL 2000 to load on the new node (successfully added to the
cluster). We are using the procedure How to add nodes to an existing
virtual server (Setup)(from BOL). When asked for computer name we entered
the SQL cluster name for the virtual server. When asked for the logon we
used the id used to log both nodes on the domain (Domain Admin & member of
Adminisytrators group on both servers). Got a screen asking for the
passwords for the ids for MSSQLSERVER & SQLSERVER AGENT. (screen was not
expected).[vbcol=seagreen]
cluster. Active node has SQL 2000 SP2 with Security Patch 0655. The new
node was successfully added to the cluster. We are trying to push SQL 2000
to the new node. The CD we are using is SQL2000 Enterprise edition with no
service packs. Once we get SQL on the new node and failover to it, we are
going to apply SQL 2000 SP3. After that we will start the process of
evicting the current node and getting a new Windows 2003 node to join the
cluster. Once SQL 2000 is on that node and we failover to that node, the
node we just added will be upgraded to Windows 2003. We have Q811272 on
registry hack when the operating systems of the cluster servers are
different and Q 294209 & Q 301600 on moving the MSDTC resource from the
cluster group to the SQL group.[vbcol=seagreen]
contains all the steps and we are entering the correct information? Plus
what's with the screen asking for the MSSQLSERVER and SQLSERVERAGENT
services password.[vbcol=seagreen]
during the install. Can't find that anywhere except for applying service
packs.
|||You can apply a service pack to a new node without taking the Virtual SQL
server offline. This is possible if the SP has already been applied to the
virtual server. See the README file for details.
When the install is asking for a virtual server name, it means the SQL
virtual server.
Install needs the passwords to create the services correctly on the new
node.
I use EMC Clariion gear and am familiar with the PowerPath software. The
system should failover correctly as long as the new node can see the virtual
disks. Ideally, the nodes should be identical, but during a transition,
this isn't always possible. I would create a small temporary LUN on the SAN
and add it to whatever group you are using on the SAN to present LUNS to
this host collection. You can then format it and make it a clustered
physical disk resource. Put it into a new, temporary virtual server (name,
disk, and IP only) that you manually create. You can then test disk
failover without affecting your SQL server.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:B70341B7-80F6-4C74-BFC6-78D7CDF655A1@.microsoft.com...
> Thanks for the info. NOTE: The questions asked relate to getting SQL on
the new node not applying SP3. I figure applying SP3 will be the easist
part. And yes I know the apps need to be down and can get a window to do
that.
>
> The Computer Name screen says it wants the name of the "virtual server"
there is a later screen (Cluster Management) where we provide the name of
the new server. So which of the two virtual server names do we use: the
one for the MSCS cluster or the one for the SQL cluster? We used the SQL
Clsuter name.
> The login requested has to have administrator priviledges on both servers
which tells me that SA is not the id to use.
>
> What about the screen that showed up that wasn't in the procedure? It
asked for the passwords for the ids used for the two services SQL uses.
> Do the apps using these databases need to be down when we install SQL on
the new node? They can be if needed.
> On your comment about the drivers: Our SAN is EMC Symmetrix. The current
working node has 2 HBAs & PowerPath (lets computer know the HBAs point to
the same disk) the new node has one HBA and no PowerPath plus the nodes have
different drivers & firmware for the HBAs. Based on your comment, I get the
feeling that failover won't work. Is this correct? By the way the new node
is in the cluster. When we use Disk Management it has an entry for the SAN
disk; however, we don't know if it will see the SAN disk correctly yet since
we can't failover without SQL. Or can we?
> Pat Hall
> Sr. Database Administrator
> pat.hall@.gilbarco.com
> -- Geoff N. Hiten wrote: --
> Ok, You guys are really trying. Major kudos for the detailed post.
> Ok, here are my notes.
> Computer name = new host name, not virtual servername. The cluster
install
> already asked for the instance name on a prior screen.
> Login info: I prefer to use the SA login, avoiding any NT permissions
> issues. assuming your cluster is in mixed mode.
> SQL Service packs. Run the SP from the node that owns the SQL group.
It
> WILL take the server offline while the SP is applied. Get over it.
You MUST
> apply SP3 or SP3 a before upgrading to Windows 2003.
> MSDTC:. Win2000 best practices - put it in the cluster group.
Win2003 Best
> Practices = make a new group. Practical experiance = I have not
seen, nor
> heard of a situation where it made a difference.
> The real difficulty is going to be making sure that 2003 can access
the[vbcol=seagreen]
> shared storage. Drivers are critical.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
> news:0D42B568-1D29-4577-9FA9-327FBF09CC3D@.microsoft.com...
to the
> cluster). We are using the procedure How to add nodes to an existing
> virtual server (Setup)(from BOL). When asked for computer name we
entered
> the SQL cluster name for the virtual server. When asked for the
logon we
> used the id used to log both nodes on the domain (Domain Admin &
member of
> Adminisytrators group on both servers). Got a screen asking for the
> passwords for the ids for MSSQLSERVER & SQLSERVER AGENT. (screen was
not
> expected).
> cluster. Active node has SQL 2000 SP2 with Security Patch 0655. The
new
> node was successfully added to the cluster. We are trying to push
SQL 2000
> to the new node. The CD we are using is SQL2000 Enterprise edition
with no
> service packs. Once we get SQL on the new node and failover to it,
we are
> going to apply SQL 2000 SP3. After that we will start the process of
> evicting the current node and getting a new Windows 2003 node to join
the
> cluster. Once SQL 2000 is on that node and we failover to that node,
the
> node we just added will be upgraded to Windows 2003. We have Q811272
on
> registry hack when the operating systems of the cluster servers are
> different and Q 294209 & Q 301600 on moving the MSDTC resource from
the
> cluster group to the SQL group.
> contains all the steps and we are entering the correct information?
Plus[vbcol=seagreen]
> what's with the screen asking for the MSSQLSERVER and SQLSERVERAGENT
> services password.
be down
> during the install. Can't find that anywhere except for applying
service
> packs.
>
>
|||But how do I get SQL Server 2000 on the new node so I can install SP3. That is my problem right now. When I follow the instructions in BOL I get kicked out after I enter the passwords for the two SQL services and click next. On the new node there is no
C:\Program Files\Miscrosoft SQL Server directory.
Do I evict the new node, install SQL 2000 up to the point of the current node, rejoin the cluster then do the procedure I 'm trying? If so, what about the system databases, backup & Data etc directories that will be on the new node which will know nothin
g of the SAN disk.
Also during this install, will my databases be affected? In other words do I need down time?
All I'm trying to do now is get the new node set up so I can perform a failover. Both nodes are Win2K at this time.
On the idea of creating a small LUN, I wish. Our SAN doesn't have any available space. All I can do is get the new node in the cluster and try a failover. It works or it doesn't. And hopefully doesn't hurt the data, if it doesn't. Talk about making s
ure we have a good backup 1st.
Pat Hall
-- Geoff N. Hiten wrote: --
You can apply a service pack to a new node without taking the Virtual SQL
server offline. This is possible if the SP has already been applied to the
virtual server. See the README file for details.
When the install is asking for a virtual server name, it means the SQL
virtual server.
Install needs the passwords to create the services correctly on the new
node.
I use EMC Clariion gear and am familiar with the PowerPath software. The
system should failover correctly as long as the new node can see the virtual
disks. Ideally, the nodes should be identical, but during a transition,
this isn't always possible. I would create a small temporary LUN on the SAN
and add it to whatever group you are using on the SAN to present LUNS to
this host collection. You can then format it and make it a clustered
physical disk resource. Put it into a new, temporary virtual server (name,
disk, and IP only) that you manually create. You can then test disk
failover without affecting your SQL server.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:B70341B7-80F6-4C74-BFC6-78D7CDF655A1@.microsoft.com...
> Thanks for the info. NOTE: The questions asked relate to getting SQL on
the new node not applying SP3. I figure applying SP3 will be the easist
part. And yes I know the apps need to be down and can get a window to do
that.[vbcol=seagreen]
there is a later screen (Cluster Management) where we provide the name of
the new server. So which of the two virtual server names do we use: the
one for the MSCS cluster or the one for the SQL cluster? We used the SQL
Clsuter name.[vbcol=seagreen]
which tells me that SA is not the id to use.[vbcol=seagreen]
asked for the passwords for the ids used for the two services SQL uses.[vbcol=seagreen]
the new node? They can be if needed.[vbcol=seagreen]
working node has 2 HBAs & PowerPath (lets computer know the HBAs point to
the same disk) the new node has one HBA and no PowerPath plus the nodes have
different drivers & firmware for the HBAs. Based on your comment, I get the
feeling that failover won't work. Is this correct? By the way the new node
is in the cluster. When we use Disk Management it has an entry for the SAN
disk; however, we don't know if it will see the SAN disk correctly yet since
we can't failover without SQL. Or can we?[vbcol=seagreen]
> Sr. Database Administrator
> pat.hall@.gilbarco.com
install[vbcol=seagreen]
> already asked for the instance name on a prior screen.
> issues. assuming your cluster is in mixed mode.
It
> WILL take the server offline while the SP is applied. Get over it.
You MUST[vbcol=seagreen]
> apply SP3 or SP3 a before upgrading to Windows 2003.
Win2003 Best
> Practices = make a new group. Practical experiance = I have not
seen, nor[vbcol=seagreen]
> heard of a situation where it made a difference.
the[vbcol=seagreen]
> shared storage. Drivers are critical.
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> www.sqlpass.org
> news:0D42B568-1D29-4577-9FA9-327FBF09CC3D@.microsoft.com...
to the
> cluster). We are using the procedure How to add nodes to an existing
> virtual server (Setup)(from BOL). When asked for computer name we
entered
> the SQL cluster name for the virtual server. When asked for the
logon we
> used the id used to log both nodes on the domain (Domain Admin &
member of
> Adminisytrators group on both servers). Got a screen asking for the
> passwords for the ids for MSSQLSERVER & SQLSERVER AGENT. (screen was
not
> expected).
> cluster. Active node has SQL 2000 SP2 with Security Patch 0655. The
new
> node was successfully added to the cluster. We are trying to push
SQL 2000
> to the new node. The CD we are using is SQL2000 Enterprise edition
with no
> service packs. Once we get SQL on the new node and failover to it,
we are
> going to apply SQL 2000 SP3. After that we will start the process of
> evicting the current node and getting a new Windows 2003 node to join
the
> cluster. Once SQL 2000 is on that node and we failover to that node,
the
> node we just added will be upgraded to Windows 2003. We have Q811272
on
> registry hack when the operating systems of the cluster servers are
> different and Q 294209 & Q 301600 on moving the MSDTC resource from
the
> cluster group to the SQL group.
> contains all the steps and we are entering the correct information?
Plus[vbcol=seagreen]
> what's with the screen asking for the MSSQLSERVER and SQLSERVERAGENT
> services password.
be down
> during the install. Can't find that anywhere except for applying
service[vbcol=seagreen]
> packs.
|||You missed an earlier critical step. You MUST run the SQL install and
remove the old node before you can add the new one. This step is in
addition to the eviction of the old node from the cluster. Until SQL has
current node information, the install will fail.
Also, make sure the service accounts and the install account are
domain-level accounts that are in the local administrators group on the new
node.
When you add a node to SQL, the virtual server remains online.
No spare or emergency space on the SAN is asking for trouble, but then
again, you already have trouble.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:2B259942-AFA3-4262-84E4-71717DBE66DB@.microsoft.com...
> But how do I get SQL Server 2000 on the new node so I can install SP3.
That is my problem right now. When I follow the instructions in BOL I get
kicked out after I enter the passwords for the two SQL services and click
next. On the new node there is no C:\Program Files\Miscrosoft SQL Server
directory.
> Do I evict the new node, install SQL 2000 up to the point of the current
node, rejoin the cluster then do the procedure I 'm trying? If so, what
about the system databases, backup & Data etc directories that will be on
the new node which will know nothing of the SAN disk.
> Also during this install, will my databases be affected? In other words
do I need down time?
> All I'm trying to do now is get the new node set up so I can perform a
failover. Both nodes are Win2K at this time.
> On the idea of creating a small LUN, I wish. Our SAN doesn't have any
available space. All I can do is get the new node in the cluster and try a
failover. It works or it doesn't. And hopefully doesn't hurt the data, if
it doesn't. Talk about making sure we have a good backup 1st.
> Pat Hall
> -- Geoff N. Hiten wrote: --
> You can apply a service pack to a new node without taking the Virtual
SQL
> server offline. This is possible if the SP has already been applied
to the
> virtual server. See the README file for details.
> When the install is asking for a virtual server name, it means the
SQL
> virtual server.
> Install needs the passwords to create the services correctly on the
new
> node.
> I use EMC Clariion gear and am familiar with the PowerPath software.
The
> system should failover correctly as long as the new node can see the
virtual
> disks. Ideally, the nodes should be identical, but during a
transition,
> this isn't always possible. I would create a small temporary LUN on
the SAN
> and add it to whatever group you are using on the SAN to present LUNS
to
> this host collection. You can then format it and make it a clustered
> physical disk resource. Put it into a new, temporary virtual server
(name,[vbcol=seagreen]
> disk, and IP only) that you manually create. You can then test disk
> failover without affecting your SQL server.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
> news:B70341B7-80F6-4C74-BFC6-78D7CDF655A1@.microsoft.com...
SQL on
> the new node not applying SP3. I figure applying SP3 will be the
easist
> part. And yes I know the apps need to be down and can get a window
to do[vbcol=seagreen]
> that.
server"
> there is a later screen (Cluster Management) where we provide the
name of
> the new server. So which of the two virtual server names do we use:
the
> one for the MSCS cluster or the one for the SQL cluster? We used the
SQL[vbcol=seagreen]
> Clsuter name.
servers[vbcol=seagreen]
> which tells me that SA is not the id to use.
It
> asked for the passwords for the ids used for the two services SQL
uses.[vbcol=seagreen]
SQL on[vbcol=seagreen]
> the new node? They can be if needed.
current
> working node has 2 HBAs & PowerPath (lets computer know the HBAs
point to
> the same disk) the new node has one HBA and no PowerPath plus the
nodes have
> different drivers & firmware for the HBAs. Based on your comment, I
get the
> feeling that failover won't work. Is this correct? By the way the
new node
> is in the cluster. When we use Disk Management it has an entry for
the SAN
> disk; however, we don't know if it will see the SAN disk correctly
yet since[vbcol=seagreen]
> we can't failover without SQL. Or can we?
post.[vbcol=seagreen]
cluster[vbcol=seagreen]
> install
permissions[vbcol=seagreen]
SQL group.[vbcol=seagreen]
> It
it.[vbcol=seagreen]
> You MUST
> Win2003 Best
not[vbcol=seagreen]
> seen, nor
access[vbcol=seagreen]
> the
message[vbcol=seagreen]
> to the
existing[vbcol=seagreen]
name we[vbcol=seagreen]
> entered
the[vbcol=seagreen]
> logon we
&[vbcol=seagreen]
> member of
for the[vbcol=seagreen]
(screen was[vbcol=seagreen]
> not
node[vbcol=seagreen]
0655. The[vbcol=seagreen]
> new
push[vbcol=seagreen]
> SQL 2000
edition[vbcol=seagreen]
> with no
to it,[vbcol=seagreen]
> we are
process of[vbcol=seagreen]
to join[vbcol=seagreen]
> the
that node,[vbcol=seagreen]
> the
Q811272[vbcol=seagreen]
> on
servers are[vbcol=seagreen]
from[vbcol=seagreen]
> the
it[vbcol=seagreen]
information?[vbcol=seagreen]
> Plus
SQLSERVERAGENT[vbcol=seagreen]
> be down
applying[vbcol=seagreen]
> service
|||Uh Oh.
When I was working with MS Support they said all I had to do was evict the node from the cluster. They checked with SQL support before responding to me. All we did was evict the node from the cluster. When I go thru the procedure and get to the screen
where I select the node to join the SQL cluster, I do not see the old node just the new node.
Maybe I need to go back to MS Support for help in getting this straightened out. I didn't realize it would be this difficult.
All ids involved meet the criteria you stated.
Thanks for the info on SQL cluster still available whilie I add the new node to the SQL cluster.
Pat Hall
Sr. DBA
Gilbarco Veeder-Root
|||Here are the necessary instruction cut directly from BOL:
--snip--
How to remove a node from an existing failover cluster (Setup)
1.. On the Welcome screen of the Microsoft SQL Server Installation Wizard,
click Next.
2.. On the Computer Name screen, click Virtual Server and specify the name
of the server from which to remove the node. Click Next.
3.. You may see an error message saying that one (or more) of the nodes of
the Microsoft Windows NT 4.0 or Microsoft Windows 2000 cluster are
unavailable. This may be because the node(s) you are attempting to remove is
damaged. The node(s) still can be removed. Click OK.
4.. On the Installation Selection screen, click Advanced Options. Click
Next.
5.. On the Advanced Options screen, click Maintain a virtual server for
failover clustering. Click Next.
6.. On the Failover Clustering screen, click Next.
You do not need to modify any IP address(es).
7.. On the Cluster Management screen, select the node and click Remove.
Click Next.
8.. On the Remote Information screen, enter login credentials for the
remote cluster node that has administrator privileges on the remote node(s)
of the cluster. Click Next.
9.. On the Setup Complete screen, click Finish.
If you are instructed to restart the computer, do so now. It is important
to read the message from SQL Server Setup when you are done with
installation. Failure to restart any of the specified nodes may cause
failures when you run the Setup program in the future on any node in the
failover cluster.
--snip--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Pat Hall" <anonymous@.discussions.microsoft.com> wrote in message
news:2893F359-FD01-49DB-8CB1-475BA25C4C5B@.microsoft.com...
> Uh Oh.
> When I was working with MS Support they said all I had to do was evict the
node from the cluster. They checked with SQL support before responding to
me. All we did was evict the node from the cluster. When I go thru the
procedure and get to the screen where I select the node to join the SQL
cluster, I do not see the old node just the new node.
> Maybe I need to go back to MS Support for help in getting this
straightened out. I didn't realize it would be this difficult.
> All ids involved meet the criteria you stated.
> Thanks for the info on SQL cluster still available whilie I add the new
node to the SQL cluster.
> Pat Hall
> Sr. DBA
> Gilbarco Veeder-Root
|||Thanks for the info. That's the procedure that MS cluster support said I didn't have to do. When we went thru the step to add the new node to the SQL cluster I did not see the old node so I think I am OK.
MS SQL support said the problem had to do with KB 273769. We licensed per processor and the CD is the original release with no SPs. They gave me a registry hack to switch to per server until I get the new node in the SQL cluster then I can switch back.
We're doing that today. I'll let you know what happens.
|||The registry hack to set the licensing to Per Seat and a large value for number of seats did the trick. Now I just need to schedule a window to apply SP2 & the security patch. Getting the window is easy, making sure all the app people are available is t
he hard part.
Pat Hall
Sr. DBA
Gilbarco Veeder-Root
No comments:
Post a Comment