Mirror of master, msdb, tempdb, or model databases.

Hi Guys,

Since,You cannot mirror the master, msdb, tempdb, or model databases.What will happen if i create new login,change existing security profile and new jobs,change of existing job on princicpal db. how these will be mirrored to other server and in case failover, how it will treat.

Thaks

Mirroring works at the database level only. dts/ssis packages, jobs etc are not mirrored. Database users are mirrored but not their corresponding SQL Server login.

You need to keep a copy of dts/ssis packages, jobs etc on the mirror server and whatever changes you make to them on the principal server, you will also have to make on the mirror server if you want to keep the servers exactly in sync.

hope this helps

Minimum permissions for SQL2005 development?

Hi
I'm trying to get started developing on this 2005 box, but I'm running
into big security problems, because this is one of those shops where
getting the most minimal level of access to the dev server (even as a
developer who should supposedly be doing something productive for the
daily rate) is harder than getting Tony Blair to tell you the Trident
launch codes.
So at the moment even Management Studio won't work. And the security
administrators are not SQL DBAs - so it's basically up to me to work
out what access I need (db_owner/sa? For a developer, on the dev
box? Forget it!), tell them this, and then go through whatever
paperwork/string-pulling/bribery/black ops are necessary to actually
get it granted.
If it was 2000 I'd have some idea, but I'm relatively new to 2005 -
developed on a "friendly" box as sa before, but never run into this.
Anyone know what permissions I'd need to:
- Create/drop/execute objects in a DB (obviously, db_datawriter and
db_datareader as well)
- Execute system stored procedures (especially sp_executesql)
- Develop, test and run SS Integration Services?
I suspect that what I'm running into at the moment is lack of
permissions in master and msdb - but it's hard to work out, when my
effective server role is something like "Unauthenticated hacker".
Apologies for my ignorance - I've never run into this level of
paranoia before.
thanks for any ideas.
seb> Minimum permissions for SQL2005 development?
The obvious answer is that you need the minimal level of permissions need to
do your job :-)

> And the security
> administrators are not SQL DBAs - so it's basically up to me to work
> out what access I need (db_owner/sa?
One would think the security admins would need to know something about SQL
security if managing SQL security is part of their job. You should only
need to tell them what you need to do and they ought to be able to know
enough to give you those permissions and nothing more.
Sysadmin role members have full control over the entire SQL Server and will
provide full control over all databases. If you don't need to change server
configuration options, install service packs and that sort of thing,
sysadmin is probably overkill. db_owner is also a powerful role but may be
appropriate if you need *complete* control over some, but not all, databases
on the server.

> Anyone know what permissions I'd need to:
> - Create/drop/execute objects in a DB (obviously, db_datawriter and
> db_datareader as well)
You'll need CREATE permissions on the target object type and ALTER on the
object's schema. If you have CONTROL on the schema, you won't need
db_datawriter and db_datareader membership to data access in that schema.

> - Execute system stored procedures (especially sp_executesql)
You should already have execute permissions on sp_executesql because execute
permissions default to public and you access master via the guest user
context. If you don't have execute permissions, the default SQL Server
permissions were changed and permissions will need to be granted via other
means.

> - Develop, test and run SS Integration Services?
Like any application, you'll SQL permissions to access the objects used by
the package. If you use msdb as the package store, you'll need to be a
member of the appropriate role (db_dtsadmin or db_dtsltduser).
Hope this helps.
Dan Guzman
SQL Server MVP
"sebt" <sebthirlway@.hotmail.com> wrote in message
news:1175679014.583549.224630@.b75g2000hsg.googlegroups.com...
> Hi
> I'm trying to get started developing on this 2005 box, but I'm running
> into big security problems, because this is one of those shops where
> getting the most minimal level of access to the dev server (even as a
> developer who should supposedly be doing something productive for the
> daily rate) is harder than getting Tony Blair to tell you the Trident
> launch codes.
> So at the moment even Management Studio won't work. And the security
> administrators are not SQL DBAs - so it's basically up to me to work
> out what access I need (db_owner/sa? For a developer, on the dev
> box? Forget it!), tell them this, and then go through whatever
> paperwork/string-pulling/bribery/black ops are necessary to actually
> get it granted.
> If it was 2000 I'd have some idea, but I'm relatively new to 2005 -
> developed on a "friendly" box as sa before, but never run into this.
> Anyone know what permissions I'd need to:
> - Create/drop/execute objects in a DB (obviously, db_datawriter and
> db_datareader as well)
> - Execute system stored procedures (especially sp_executesql)
> - Develop, test and run SS Integration Services?
> I suspect that what I'm running into at the moment is lack of
> permissions in master and msdb - but it's hard to work out, when my
> effective server role is something like "Unauthenticated hacker".
> Apologies for my ignorance - I've never run into this level of
> paranoia before.
> thanks for any ideas.
>
> seb
>|||Hello Seb,
You need minimum level permission of db_ddladmin fixed database role so that
you will able to create objects in respective database, and always create
objects as DBO so that it won't result into broken ownership chain.
Goodluck!
Cheers,
MB
"sebt" <sebthirlway@.hotmail.com> wrote in message
news:1175679014.583549.224630@.b75g2000hsg.googlegroups.com...
> Hi
> I'm trying to get started developing on this 2005 box, but I'm running
> into big security problems, because this is one of those shops where
> getting the most minimal level of access to the dev server (even as a
> developer who should supposedly be doing something productive for the
> daily rate) is harder than getting Tony Blair to tell you the Trident
> launch codes.
> So at the moment even Management Studio won't work. And the security
> administrators are not SQL DBAs - so it's basically up to me to work
> out what access I need (db_owner/sa? For a developer, on the dev
> box? Forget it!), tell them this, and then go through whatever
> paperwork/string-pulling/bribery/black ops are necessary to actually
> get it granted.
> If it was 2000 I'd have some idea, but I'm relatively new to 2005 -
> developed on a "friendly" box as sa before, but never run into this.
> Anyone know what permissions I'd need to:
> - Create/drop/execute objects in a DB (obviously, db_datawriter and
> db_datareader as well)
> - Execute system stored procedures (especially sp_executesql)
> - Develop, test and run SS Integration Services?
> I suspect that what I'm running into at the moment is lack of
> permissions in master and msdb - but it's hard to work out, when my
> effective server role is something like "Unauthenticated hacker".
> Apologies for my ignorance - I've never run into this level of
> paranoia before.
> thanks for any ideas.
>
> seb
>

Minimum level of rights for a SQL Server DBA.

Previously, DBAs in our company used to have local machine administrator
access on the SQL Server boxes. As part of tightening server security, those
rights have been taken away from DBAs (in some cases they have been added to
'Power Users' group).
In order to install SQL Server, the account need to be a local machine
administrator (that's given otherwise installation gives error).
But, what type of minimal rights should be given to DBAs on the server
resources to let that person function properly?
When I am talking about resources, I mean rights to write to specific
directories like
* SQL Server programs/tools
* Common DLLs (in C:\Program files\common files...)
* Local backup directories
* Directory for snapshot/transactional replication transfer data.
And right to execute programs/utilities on the server like
* Perfmon (for system tuning/performance monitoring)
* Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
dependencies).
Is there anything that is not needed here or, alternatively, is there
anything that I missed?
Another dimension of this issue is the OS login access that is needed to run
the SQL Server services (needed for remote backups and replication).
Any help will be greatly appreciated!
Regards,
MZeeshan
At my last company, I didnt have admin rights... just SA. 90% of the time
it was fine. The other 10% it sucked. Common things I needed someone to hold
my hand on were:
1. Service restarts.
2. Hotfix/ service packs.
3. Set up stuff like Log Shipping where directory access is needed.
4. Wanting to just see how much disk space I had left on my backup drive.
5. Replication Snapshot.
I know you already mentioned alot of these. The problem is that when the DBA
needs these things, alot of time he needs them NOW. Not once he can have
someone come to his desk and log in as Admin. But like I said, 90% of the
time it was fine and I actually would prefer it. SA is usually good enough.
Any less than SA and a DBA cant get his work done.
"MZeeshan" <mzeeshan@.community.nospam> wrote in message
news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
> Previously, DBAs in our company used to have local machine administrator
> access on the SQL Server boxes. As part of tightening server security,
> those
> rights have been taken away from DBAs (in some cases they have been added
> to
> 'Power Users' group).
> In order to install SQL Server, the account need to be a local machine
> administrator (that's given otherwise installation gives error).
> But, what type of minimal rights should be given to DBAs on the server
> resources to let that person function properly?
> When I am talking about resources, I mean rights to write to specific
> directories like
> * SQL Server programs/tools
> * Common DLLs (in C:\Program files\common files...)
> * Local backup directories
> * Directory for snapshot/transactional replication transfer data.
> And right to execute programs/utilities on the server like
> * Perfmon (for system tuning/performance monitoring)
> * Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
> dependencies).
> Is there anything that is not needed here or, alternatively, is there
> anything that I missed?
> Another dimension of this issue is the OS login access that is needed to
> run
> the SQL Server services (needed for remote backups and replication).
> Any help will be greatly appreciated!
> --
> Regards,
> MZeeshan
>
|||Thanks!
Anyone? any other ideas?
Regards,
MZeeshan
"ChrisR" wrote:

> At my last company, I didnt have admin rights... just SA. 90% of the time
> it was fine. The other 10% it sucked. Common things I needed someone to hold
> my hand on were:
> 1. Service restarts.
> 2. Hotfix/ service packs.
> 3. Set up stuff like Log Shipping where directory access is needed.
> 4. Wanting to just see how much disk space I had left on my backup drive.
> 5. Replication Snapshot.
> I know you already mentioned alot of these. The problem is that when the DBA
> needs these things, alot of time he needs them NOW. Not once he can have
> someone come to his desk and log in as Admin. But like I said, 90% of the
> time it was fine and I actually would prefer it. SA is usually good enough.
> Any less than SA and a DBA cant get his work done.
>
> "MZeeshan" <mzeeshan@.community.nospam> wrote in message
> news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
>
>
|||Hi MZeeshan,
If you need OS login access that is needed to run the SQL Server services
(needed for remote backups and replication). I think give DBA local
administrator privilege is necessary.
BTW, you are recommanded using the tools below to ensure the security of
your product server.
Best Practices Analyzer Tool for Microsoft SQL Server 2000 1.0
http://www.microsoft.com/downloads/d...=en&familyid=B
352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
Since this is a consultation type issue, you can contact Advisory Services
(AS) . Microsoft Advisory Services provides short-term advice and guidance
for problems not covered by Problem Resolution Service as well as requests
for consultative assistance for design, development and deployment issues.
You may call this number to get Advisory Services: (800) 936-5200.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Minimum level of rights for a SQL Server DBA.

Previously, DBAs in our company used to have local machine administrator
access on the SQL Server boxes. As part of tightening server security, those
rights have been taken away from DBAs (in some cases they have been added to
'Power Users' group).
In order to install SQL Server, the account need to be a local machine
administrator (that's given otherwise installation gives error).
But, what type of minimal rights should be given to DBAs on the server
resources to let that person function properly?
When I am talking about resources, I mean rights to write to specific
directories like
* SQL Server programs/tools
* Common DLLs (in C:\Program files\common files...)
* Local backup directories
* Directory for snapshot/transactional replication transfer data.
And right to execute programs/utilities on the server like
* Perfmon (for system tuning/performance monitoring)
* Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
dependencies).
Is there anything that is not needed here or, alternatively, is there
anything that I missed?
Another dimension of this issue is the OS login access that is needed to run
the SQL Server services (needed for remote backups and replication).
Any help will be greatly appreciated!
--
Regards,
MZeeshanAt my last company, I didnt have admin rights... just SA. 90% of the time
it was fine. The other 10% it sucked. Common things I needed someone to hold
my hand on were:
1. Service restarts.
2. Hotfix/ service packs.
3. Set up stuff like Log Shipping where directory access is needed.
4. Wanting to just see how much disk space I had left on my backup drive.
5. Replication Snapshot.
I know you already mentioned alot of these. The problem is that when the DBA
needs these things, alot of time he needs them NOW. Not once he can have
someone come to his desk and log in as Admin. But like I said, 90% of the
time it was fine and I actually would prefer it. SA is usually good enough.
Any less than SA and a DBA cant get his work done.
"MZeeshan" <mzeeshan@.community.nospam> wrote in message
news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
> Previously, DBAs in our company used to have local machine administrator
> access on the SQL Server boxes. As part of tightening server security,
> those
> rights have been taken away from DBAs (in some cases they have been added
> to
> 'Power Users' group).
> In order to install SQL Server, the account need to be a local machine
> administrator (that's given otherwise installation gives error).
> But, what type of minimal rights should be given to DBAs on the server
> resources to let that person function properly?
> When I am talking about resources, I mean rights to write to specific
> directories like
> * SQL Server programs/tools
> * Common DLLs (in C:\Program files\common files...)
> * Local backup directories
> * Directory for snapshot/transactional replication transfer data.
> And right to execute programs/utilities on the server like
> * Perfmon (for system tuning/performance monitoring)
> * Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
> dependencies).
> Is there anything that is not needed here or, alternatively, is there
> anything that I missed?
> Another dimension of this issue is the OS login access that is needed to
> run
> the SQL Server services (needed for remote backups and replication).
> Any help will be greatly appreciated!
> --
> Regards,
> MZeeshan
>|||Thanks!
Anyone? any other ideas?
--
Regards,
MZeeshan
"ChrisR" wrote:
> At my last company, I didnt have admin rights... just SA. 90% of the time
> it was fine. The other 10% it sucked. Common things I needed someone to hold
> my hand on were:
> 1. Service restarts.
> 2. Hotfix/ service packs.
> 3. Set up stuff like Log Shipping where directory access is needed.
> 4. Wanting to just see how much disk space I had left on my backup drive.
> 5. Replication Snapshot.
> I know you already mentioned alot of these. The problem is that when the DBA
> needs these things, alot of time he needs them NOW. Not once he can have
> someone come to his desk and log in as Admin. But like I said, 90% of the
> time it was fine and I actually would prefer it. SA is usually good enough.
> Any less than SA and a DBA cant get his work done.
>
> "MZeeshan" <mzeeshan@.community.nospam> wrote in message
> news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
> > Previously, DBAs in our company used to have local machine administrator
> > access on the SQL Server boxes. As part of tightening server security,
> > those
> > rights have been taken away from DBAs (in some cases they have been added
> > to
> > 'Power Users' group).
> >
> > In order to install SQL Server, the account need to be a local machine
> > administrator (that's given otherwise installation gives error).
> >
> > But, what type of minimal rights should be given to DBAs on the server
> > resources to let that person function properly?
> >
> > When I am talking about resources, I mean rights to write to specific
> > directories like
> > * SQL Server programs/tools
> > * Common DLLs (in C:\Program files\common files...)
> > * Local backup directories
> > * Directory for snapshot/transactional replication transfer data.
> >
> > And right to execute programs/utilities on the server like
> >
> > * Perfmon (for system tuning/performance monitoring)
> > * Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
> > dependencies).
> >
> > Is there anything that is not needed here or, alternatively, is there
> > anything that I missed?
> >
> > Another dimension of this issue is the OS login access that is needed to
> > run
> > the SQL Server services (needed for remote backups and replication).
> >
> > Any help will be greatly appreciated!
> >
> > --
> > Regards,
> > MZeeshan
> >
>
>|||Hi MZeeshan,
If you need OS login access that is needed to run the SQL Server services
(needed for remote backups and replication). I think give DBA local
administrator privilege is necessary.
BTW, you are recommanded using the tools below to ensure the security of
your product server.
Best Practices Analyzer Tool for Microsoft SQL Server 2000 1.0
http://www.microsoft.com/downloads/details.aspx?displayla%20ng=en&familyid=B
352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
Since this is a consultation type issue, you can contact Advisory Services
(AS) . Microsoft Advisory Services provides short-term advice and guidance
for problems not covered by Problem Resolution Service as well as requests
for consultative assistance for design, development and deployment issues.
You may call this number to get Advisory Services: (800) 936-5200.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Minimum level of rights for a SQL Server DBA.

Previously, DBAs in our company used to have local machine administrator
access on the SQL Server boxes. As part of tightening server security, those
rights have been taken away from DBAs (in some cases they have been added to
'Power Users' group).
In order to install SQL Server, the account need to be a local machine
administrator (that's given otherwise installation gives error).
But, what type of minimal rights should be given to DBAs on the server
resources to let that person function properly?
When I am talking about resources, I mean rights to write to specific
directories like
* SQL Server programs/tools
* Common DLLs (in C:\Program files\common files...)
* Local backup directories
* Directory for snapshot/transactional replication transfer data.
And right to execute programs/utilities on the server like
* Perfmon (for system tuning/performance monitoring)
* Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
dependencies).
Is there anything that is not needed here or, alternatively, is there
anything that I missed?
Another dimension of this issue is the OS login access that is needed to run
the SQL Server services (needed for remote backups and replication).
Any help will be greatly appreciated!
Regards,
MZeeshanAt my last company, I didnt have admin rights... just SA. 90% of the time
it was fine. The other 10% it sucked. Common things I needed someone to hold
my hand on were:
1. Service restarts.
2. Hotfix/ service packs.
3. Set up stuff like Log Shipping where directory access is needed.
4. Wanting to just see how much disk space I had left on my backup drive.
5. Replication Snapshot.
I know you already mentioned alot of these. The problem is that when the DBA
needs these things, alot of time he needs them NOW. Not once he can have
someone come to his desk and log in as Admin. But like I said, 90% of the
time it was fine and I actually would prefer it. SA is usually good enough.
Any less than SA and a DBA cant get his work done.
"MZeeshan" <mzeeshan@.community.nospam> wrote in message
news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
> Previously, DBAs in our company used to have local machine administrator
> access on the SQL Server boxes. As part of tightening server security,
> those
> rights have been taken away from DBAs (in some cases they have been added
> to
> 'Power Users' group).
> In order to install SQL Server, the account need to be a local machine
> administrator (that's given otherwise installation gives error).
> But, what type of minimal rights should be given to DBAs on the server
> resources to let that person function properly?
> When I am talking about resources, I mean rights to write to specific
> directories like
> * SQL Server programs/tools
> * Common DLLs (in C:\Program files\common files...)
> * Local backup directories
> * Directory for snapshot/transactional replication transfer data.
> And right to execute programs/utilities on the server like
> * Perfmon (for system tuning/performance monitoring)
> * Services (starting/stopping MSSQLSERVER/SQL Agent esp. if there are
> dependencies).
> Is there anything that is not needed here or, alternatively, is there
> anything that I missed?
> Another dimension of this issue is the OS login access that is needed to
> run
> the SQL Server services (needed for remote backups and replication).
> Any help will be greatly appreciated!
> --
> Regards,
> MZeeshan
>|||Thanks!
Anyone? any other ideas?
--
Regards,
MZeeshan
"ChrisR" wrote:

> At my last company, I didnt have admin rights... just SA. 90% of the time
> it was fine. The other 10% it sucked. Common things I needed someone to ho
ld
> my hand on were:
> 1. Service restarts.
> 2. Hotfix/ service packs.
> 3. Set up stuff like Log Shipping where directory access is needed.
> 4. Wanting to just see how much disk space I had left on my backup drive.
> 5. Replication Snapshot.
> I know you already mentioned alot of these. The problem is that when the D
BA
> needs these things, alot of time he needs them NOW. Not once he can have
> someone come to his desk and log in as Admin. But like I said, 90% of the
> time it was fine and I actually would prefer it. SA is usually good enough
.
> Any less than SA and a DBA cant get his work done.
>
> "MZeeshan" <mzeeshan@.community.nospam> wrote in message
> news:CD58C09D-1874-46A3-AA05-344727CA35F3@.microsoft.com...
>
>|||Hi MZeeshan,
If you need OS login access that is needed to run the SQL Server services
(needed for remote backups and replication). I think give DBA local
administrator privilege is necessary.
BTW, you are recommanded using the tools below to ensure the security of
your product server.
Best Practices Analyzer Tool for Microsoft SQL Server 2000 1.0
http://www.microsoft.com/downloads/...g=en&familyid=B
352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
Since this is a consultation type issue, you can contact Advisory Services
(AS) . Microsoft Advisory Services provides short-term advice and guidance
for problems not covered by Problem Resolution Service as well as requests
for consultative assistance for design, development and deployment issues.
You may call this number to get Advisory Services: (800) 936-5200.
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.

Minimal required DLLS for Named Pipes connection?

I have a work around for an application use Integrated Security
instead of SQL Security (which is great). I need to use named pipes
for this to work.
I only got it to work after I did a SQL 2005 Connectivity and Client
Tools install which
installed everything but the Server services. Boss doesn't like this
approach, wants minimal install.
My questions:
Are there just a few DLLs that I need to connect to SQL Server with
named pipes only?
Do I need to Register the DLLs using REGSRV32.EXE?
Thanks
ErikYou can probably get this to work with only installing the client
connectivity. I wouldn't try to hack it.
Jason Massie
http://statisticsio.com
"Erik G" <info@.fdaregulatory.com> wrote in message
news:1194885570.885338.225030@.v3g2000hsg.googlegroups.com...
>I have a work around for an application use Integrated Security
> instead of SQL Security (which is great). I need to use named pipes
> for this to work.
> I only got it to work after I did a SQL 2005 Connectivity and Client
> Tools install which
> installed everything but the Server services. Boss doesn't like this
> approach, wants minimal install.
> My questions:
> Are there just a few DLLs that I need to connect to SQL Server with
> named pipes only?
> Do I need to Register the DLLs using REGSRV32.EXE?
> Thanks
> Erik
>

Minimal required DLLS for Named Pipes connection?

I have a work around for an application use Integrated Security
instead of SQL Security (which is great). I need to use named pipes
for this to work.
I only got it to work after I did a SQL 2005 Connectivity and Client
Tools install which
installed everything but the Server services. Boss doesn't like this
approach, wants minimal install.
My questions:
Are there just a few DLLs that I need to connect to SQL Server with
named pipes only?
Do I need to Register the DLLs using REGSRV32.EXE?
Thanks
Erik
You can probably get this to work with only installing the client
connectivity. I wouldn't try to hack it.
Jason Massie
http://statisticsio.com
"Erik G" <info@.fdaregulatory.com> wrote in message
news:1194885570.885338.225030@.v3g2000hsg.googlegro ups.com...
>I have a work around for an application use Integrated Security
> instead of SQL Security (which is great). I need to use named pipes
> for this to work.
> I only got it to work after I did a SQL 2005 Connectivity and Client
> Tools install which
> installed everything but the Server services. Boss doesn't like this
> approach, wants minimal install.
> My questions:
> Are there just a few DLLs that I need to connect to SQL Server with
> named pipes only?
> Do I need to Register the DLLs using REGSRV32.EXE?
> Thanks
> Erik
>
sql

Migration Of MSSQL instance along with security permissions

Hi All,

This is the scenario. Basically i work for a web hosting company now we have taken over control of a competitor and would like to migrate there existing data to our own MSSQL server's in order to integrate them into our automatic system etc etc ...

The current system is running MSSQL7.

The system been copied to is MSSQL2K.

Objectives:

Retain all security accounts listed on the MSSQL7 system and use them on the MSSQL2K system. This includes all the logins that use standard MSSQL login's. (Reason : To ensure that all the customers ASP pages work after the DB's have been copied.)
Backup all the databases on the MSSQL7 and restore them to the MSSQL2K system. Unfortunately system is running on a different network with firewall's etc in between. What type of maintenance plan and how should i implement the requirement to keep all the login account's?
Any help greatly appreciated......
thxone of the option can be like take all backups on either hdd or tape then connect it to ur server copy it from previous one to new one.
to copy all login info etc u can write a script if u need the script i can send u next time (this will take the info to a cursor and one by one it wil update.)
as far as sql 7 database schema and 2k schema is concerned i dont think it will be a problem.
this is an intersting case pl update me|||Hi ranjan apologies for not replying sooner (did not know if anyone had replied). I agree when u state that u dont think either that the difference between porting to 2000 is going to cause an issue. I have restored all the databases now but am in need of a little help / inspiration on how to port over the login names. Perhaps you can help or have a script that performs this task. Regards the script u have for updating i presume its independent to the current logins that are on the SQL2K system at present. How is this done?