hardware upgrade of active/active cluster

I'm planning a hardware upgrade of our active/active dual node Windows
2000 sql cluster. Hostnames and IP addresses will remain unchanged.
Here's a high level overview of my plan..
1. move all cluster groups/resources to node 2
2. shutdown sql services on node 1
3. uninstall MSCS on node 1
4. evict node 1 from cluster using cluster administrator on node 2
5. power down node 1
6. reset node 1 account in domain
7. add new node 1 to domain
8. install MSCS on new node 1
9. install sql server on new node 1
10. install sql sp2 on new node 1
11. add new node 1 to existing cluster
12. verify that all resources can move to new node 1 correctly
** repeat for node 2
I know this has been discussed several times before in this newsgroup,
but there's a few extra steps in there that I believe have not been
addressed in the past. Does the above look accurate and also is it
feasible to roll back to a ghost image and backup of the quarum in the
event of a problem with either server?
Thanks in advance,
David
Step 1.5 Uninstall SQL from Node 1. If you do not do this step, you cannot
do step 9. Uninstalling SQL also tells the existing cluster not to look for
that node any longer as a valid SQL host node. You can do it as step 8.5,
but you will have to wait on some timeouts since the node is no onger there.
I haven't tried a ghost of the quorum as a restore technique, but I suspect
that given the SQL configuration changes, it wouldn't work.
Since you are reusing node names, make sure you have removed all traces of
the nodes from Active Directory and allowed it to globally synch before
trying to add the machines back in.
IMHO, I would take the opportunity to upgrade to Windows 2003 as a host OS
during the upgrade. In that case, you would need to be on at least SP3a
before starting the cluster upgrade.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<davidawest@.gmail.com> wrote in message
news:1132725533.573424.291710@.z14g2000cwz.googlegr oups.com...
> I'm planning a hardware upgrade of our active/active dual node Windows
> 2000 sql cluster. Hostnames and IP addresses will remain unchanged.
> Here's a high level overview of my plan..
> 1. move all cluster groups/resources to node 2
> 2. shutdown sql services on node 1
> 3. uninstall MSCS on node 1
> 4. evict node 1 from cluster using cluster administrator on node 2
> 5. power down node 1
> 6. reset node 1 account in domain
> 7. add new node 1 to domain
> 8. install MSCS on new node 1
> 9. install sql server on new node 1
> 10. install sql sp2 on new node 1
> 11. add new node 1 to existing cluster
> 12. verify that all resources can move to new node 1 correctly
> ** repeat for node 2
> I know this has been discussed several times before in this newsgroup,
> but there's a few extra steps in there that I believe have not been
> addressed in the past. Does the above look accurate and also is it
> feasible to roll back to a ghost image and backup of the quarum in the
> event of a problem with either server?
> Thanks in advance,
> David
>

Hardware Suggestions please

We are planning to purchase a new server for our database application.
The server will be running Sql Server 2005 as the RDBMS. The
application is expected to be used by around 10-15 people (power
users). We are expecting some heavy importing(inserting) of data into
the database and also lots of reading. There would be many tables that
would be very huge (more than a million rows).
We have looked at the System requirements for Sql Server 2005 but that
is the lowest common denominator. We have therefore decided on the
following hardware configuration:
Intel Pentium IV
4 GB RAM
500 GB HARDDISK ( may be as two disks)
Any additions/corrections to the above list would be appreciated.
ThanksThere is an article by Kevin Kline called "Bare Metal Tuning" that
gives some great advice on what hardware to use for SQL Server; here's
a link to it, but you need to be a subscriber to SQL Server magazine
(which you should purchase anyway; great resource).
http://www.sqlmag.com/Article/Artic...rver_46492.html
Just off the top of my head, though, you need to really think about
drives and arrangement. A database server needs at a minimum two
physical disk cofigured; one for database files, and one for log files.
I recommend three (add another for tempdb). RAID 10 is the best
setup, but you can use RAID 5.
Others may have more advice, but that's what I could think off in the
short term.
Stu|||You didn't say how many CPU's. Since you're expecting a lot of querying,
going with just one isn't an option. Consider 2 dual-core CPU's. Also,
even though you may have enough storage capacity in your disks, performance
may not be up to the task. The more physical disks you have, the faster
things go - if you go with a RAID10 (striped and mirrored) configuration.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"S Chapman" <s_chapman47@.hotmail.co.uk> wrote in message
news:1146824123.095677.27230@.i39g2000cwa.googlegroups.com...
We are planning to purchase a new server for our database application.
The server will be running Sql Server 2005 as the RDBMS. The
application is expected to be used by around 10-15 people (power
users). We are expecting some heavy importing(inserting) of data into
the database and also lots of reading. There would be many tables that
would be very huge (more than a million rows).
We have looked at the System requirements for Sql Server 2005 but that
is the lowest common denominator. We have therefore decided on the
following hardware configuration:
Intel Pentium IV
4 GB RAM
500 GB HARDDISK ( may be as two disks)
Any additions/corrections to the above list would be appreciated.
Thanks

hardware sizing

Hi,
We are running SQL Server 7.0 Standard Edition and
planning to upgrade to SQL Server 2000 Standard Edition
in a new hardware. Present hardware is having 2.4GB RAM
with 4 processor of 199MHZ . We are planning buy new
hardware with 3GB with 4 Processor of 1.4GHZ. According
to SQL Server documentation if its more than 2GB we have
to get Enterprise edition.
Here is my question:
Can we just allocate 2GB for SQL Server and just use
Standare edition and leave the extra 1GB for other
applications?
Your answers will be greately appriciated.
Thanks,
Mani.Yes, that will work just fine. Actually, SQL will top out at around 1.7GB
with standard edition, leaving 1.3 for OS and other application components,
should you have them
"Mani" <mani@.macdermid.com> wrote in message
news:014e01c34e3a$2be2a810$a501280a@.phx.gbl...
> Hi,
> We are running SQL Server 7.0 Standard Edition and
> planning to upgrade to SQL Server 2000 Standard Edition
> in a new hardware. Present hardware is having 2.4GB RAM
> with 4 processor of 199MHZ . We are planning buy new
> hardware with 3GB with 4 Processor of 1.4GHZ. According
> to SQL Server documentation if its more than 2GB we have
> to get Enterprise edition.
> Here is my question:
> Can we just allocate 2GB for SQL Server and just use
> Standare edition and leave the extra 1GB for other
> applications?
>
> Your answers will be greately appriciated.
> Thanks,
> Mani.
>

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAID
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-Dan
Hi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan
|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low in
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAID
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-DanHi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:
> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low in
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:
> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAI
D
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-DanHi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a R
AID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years b
y
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year
5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to ou
r
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously
.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low i
n
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a R
AID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years b
y
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year
5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to ou
r
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

handling different Timezones

I planning on using replication(merge most likely) in an environment where
the subscribers will be in different timezones. Is there way to convert the
datetime fields from the subscriber's to the local database timezone to the
publishers, and vice versa?
Thanks
+---+
William F. Kinsley
Sr. Design Engineer
NextGen Healthcare Info. Sys. Inc
Normally this is done on the application level.
There is no way, other than storing the time as UTC or with time zone
information, that I am aware of doing this.
"William F. Kinsley" <bacardi@.online.nospam> wrote in message
news:%23s5YuzHuEHA.1280@.TK2MSFTNGP10.phx.gbl...
>I planning on using replication(merge most likely) in an environment where
> the subscribers will be in different timezones. Is there way to convert
> the
> datetime fields from the subscriber's to the local database timezone to
> the
> publishers, and vice versa?
> Thanks
> --
> +---+
> William F. Kinsley
> Sr. Design Engineer
> NextGen Healthcare Info. Sys. Inc
>
|||Hi William,
Thanks for your post.
From your descriptions, I understood you would like to know whether there
will be any problems when replicating between different time zones. Have I
understood you? Correct me if I was wrong.
Based on my scope, it won't. We know of many cases where merge is
successfully running across time zones (merge wouldn't be too valuable if
it couldn't ). If you have a look at the usage of getdate in merge's stored
procuedres(identifying those stored procedures would have been useful ),
you will find that merge history tables' use of a datetime (that was
created by getdate) should not be a concern.
Additionally, there is some BOL excerpt for your reference
============
The generation column in these tables acts as a logical clock indicating
when a row was last updated at a given site. Actual datetime values are not
used for marking when changes occur, or deciding conflicts, and there is no
dependence on synchronized clocks between sites. This makes the conflict
detection and resolution algorithms more resilient to time zone differences
and differences between physical clocks on multiple servers. At a given
site, the generation numbers correspond to the order in which changes were
performed by the Merge Agent or by a user at that site.
============
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Thanks for such a detailed reply, this was really not my question, but still
was very helpful. My question is, if I have a user table with a datetime
column, is there a way for the replication process to automatically convert
the datetime from the source databases timezone to the target database's
time zone? I would prefer not to store everything as UTC since I will have
user created reporting on the data.
Thanks
Bill
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:VIGUFEMuEHA.464@.cpmsftngxa10.phx.gbl...
> Hi William,
> Thanks for your post.
> From your descriptions, I understood you would like to know whether there
> will be any problems when replicating between different time zones. Have I
> understood you? Correct me if I was wrong.
> Based on my scope, it won't. We know of many cases where merge is
> successfully running across time zones (merge wouldn't be too valuable if
> it couldn't ). If you have a look at the usage of getdate in merge's
stored
> procuedres(identifying those stored procedures would have been useful ),
> you will find that merge history tables' use of a datetime (that was
> created by getdate) should not be a concern.
> Additionally, there is some BOL excerpt for your reference
> ============
> The generation column in these tables acts as a logical clock indicating
> when a row was last updated at a given site. Actual datetime values are
not
> used for marking when changes occur, or deciding conflicts, and there is
no
> dependence on synchronized clocks between sites. This makes the conflict
> detection and resolution algorithms more resilient to time zone
differences
> and differences between physical clocks on multiple servers. At a given
> site, the generation numbers correspond to the order in which changes were
> performed by the Merge Agent or by a user at that site.
> ============
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
I am sorry for my poor understanding.
If so, I think, as Hilary Cotter had said, there is no such funcationality
provided in SQL Server 2000 and you will have to do it in application
level.
However, it is a great idea to have such expand feature and I'd recommend
that you forward the recommendation to the Microsoft Wish Program:
mswish@.microsoft.com.
Hope the this will be considered in the furture version of SQL Server.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||I was afraid that was going to be the answer, Thank you for your help
Bill
""Michael Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:qBXAuAmuEHA.2692@.cpmsftngxa10.phx.gbl...
> Hi Bill,
> I am sorry for my poor understanding.
> If so, I think, as Hilary Cotter had said, there is no such funcationality
> provided in SQL Server 2000 and you will have to do it in application
> level.
> However, it is a great idea to have such expand feature and I'd recommend
> that you forward the recommendation to the Microsoft Wish Program:
> mswish@.microsoft.com.
> Hope the this will be considered in the furture version of SQL Server.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
Welcome!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!