Showing posts with label local. Show all posts
Showing posts with label local. Show all posts

Tuesday, March 20, 2012

Active Directory/ADSI connection problems...Here's the correct syntax

I am having weird problems using ADSI and SQL Server. Our local intranet is ASP with a SQL database on Windows 2003 Server. It uses Active Directory (via ADSI linked server) to get authenicate users, etc.

Every now and then (about once a month) the SQL connection to AD will "crash". The following error is what I see when it has crashed:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB error trace [OLE/DB Provider 'ADSDSOObject' ICommandText::Execute returned 0x80040e37].

Sometimes it will come back on its own later, others are solved by a server reboot. Here is how my SQL query looks:

SELECT adspath
FROM OPENQUERY(ADSI,
'<LDAP://DC=servername,DC=net>;(&(objectCategory=Person)(objectClass=user));adspath;subtree')
Rowset_1
WHERE (sn <> '')

Where can I start to get to the bottom of this?Anyone?|||

Is your issue resolved?

Thanks

|||I have the same problem, please if you solve it please help me fix it.|||

Have you gotten anywhere with your problem?

This is what was found in our SQL Error logs: "Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b".

Our problem occurs from our weekly reboot - so we see the error toward the top of the log. This error seems to be occuring frequently on our servers lately. It is not only causing outage problems on our ADSI linked servers but we have a new implementation of an application that uses impersonation(Kerberos) from Web & Sharepoint servers to SQL Server that is about to go to production that recently shared in this problem also.

It seems to be due to the fact that MSDTC is not available when SQL Server starts. We are going to be trying a registry key fix to force a dependency that was recommended. We will see after this weekend.

|||

Just to follow-up:

It's been a month now and the fix seems to have worked. The originator of this thread had problems with SQL Server on Windows 2003. But in our systems, the servers affected are SQL Servers on Windows 2000 only, both SQL Server 2000 and 2005.

Add the "MSDTC" to the registry to force SQL Server to be dependent on MSDTC service (where MSSQL is the default instance):

Key: [HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSSQL]

Value Name: DependOnService

Value Type : REG_MULTI_SZ

Value: MSDTC

|||

Almost the whole issue is syntax related.

Linking SQL Server to Active Directory is tricky. and Microsoft support/help isn't very intuitive for this.
Check a few things first...
1. two single quotes not double.
2. Make connection w/out security context.


Follow this syntax:
EXEC master.dbo.sp_addlinkedserver @.server = N'ADSI',
@.srvproduct=N'Active Directory Services', @.provider=N'ADsDSOObject',
@.datasrc=N'Servername.domain.com' --AKA the full computer name of the AD server

Then execute the openquery like this:

select * from openquery
(
ADSI,'SELECT name
FROM ''LDAP://Servername.domain.com''
WHERE objectCategory = ''Person'' AND objectClass = ''user''
')

Active Directory/ADSI connection problems...help!

I am having weird problems using ADSI and SQL Server. Our local intranet is ASP with a SQL database on Windows 2003 Server. It uses Active Directory (via ADSI linked server) to get authenicate users, etc.

Every now and then (about once a month) the SQL connection to AD will "crash". The following error is what I see when it has crashed:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB error trace [OLE/DB Provider 'ADSDSOObject' ICommandText::Execute returned 0x80040e37].

Sometimes it will come back on its own later, others are solved by a server reboot. Here is how my SQL query looks:

SELECT adspath
FROM OPENQUERY(ADSI,
'<LDAP://DC=servername,DC=net>;(&(objectCategory=Person)(objectClass=user));adspath;subtree')
Rowset_1
WHERE (sn <> '')

Where can I start to get to the bottom of this?Anyone?|||

Is your issue resolved?

Thanks

|||I have the same problem, please if you solve it please help me fix it.|||

Have you gotten anywhere with your problem?

This is what was found in our SQL Error logs: "Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b".

Our problem occurs from our weekly reboot - so we see the error toward the top of the log. This error seems to be occuring frequently on our servers lately. It is not only causing outage problems on our ADSI linked servers but we have a new implementation of an application that uses impersonation(Kerberos) from Web & Sharepoint servers to SQL Server that is about to go to production that recently shared in this problem also.

It seems to be due to the fact that MSDTC is not available when SQL Server starts. We are going to be trying a registry key fix to force a dependency that was recommended. We will see after this weekend.

|||

Just to follow-up:

It's been a month now and the fix seems to have worked. The originator of this thread had problems with SQL Server on Windows 2003. But in our systems, the servers affected are SQL Servers on Windows 2000 only, both SQL Server 2000 and 2005.

Add the "MSDTC" to the registry to force SQL Server to be dependent on MSDTC service (where MSSQL is the default instance):

Key: [HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSSQL]

Value Name: DependOnService

Value Type : REG_MULTI_SZ

Value: MSDTC

|||

Almost the whole issue is syntax related.

Linking SQL Server to Active Directory is tricky. and Microsoft support/help isn't very intuitive for this.
Check a few things first...
1. two single quotes not double.
2. Make connection w/out security context.


Follow this syntax:
EXEC master.dbo.sp_addlinkedserver @.server = N'ADSI',
@.srvproduct=N'Active Directory Services', @.provider=N'ADsDSOObject',
@.datasrc=N'Servername.domain.com' --AKA the full computer name of the AD server

Then execute the openquery like this:

select * from openquery
(
ADSI,'SELECT name
FROM ''LDAP://Servername.domain.com''
WHERE objectCategory = ''Person'' AND objectClass = ''user''
')

Active Directory/ADSI connection problems...help!

I am having weird problems using ADSI and SQL Server. Our local intranet is ASP with a SQL database on Windows 2003 Server. It uses Active Directory (via ADSI linked server) to get authenicate users, etc.

Every now and then (about once a month) the SQL connection to AD will "crash". The following error is what I see when it has crashed:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB error trace [OLE/DB Provider 'ADSDSOObject' ICommandText::Execute returned 0x80040e37].

Sometimes it will come back on its own later, others are solved by a server reboot. Here is how my SQL query looks:

SELECT adspath
FROM OPENQUERY(ADSI,
'<LDAP://DC=servername,DC=net>;(&(objectCategory=Person)(objectClass=user));adspath;subtree')
Rowset_1
WHERE (sn <> '')

Where can I start to get to the bottom of this?Anyone?|||

Is your issue resolved?

Thanks

|||I have the same problem, please if you solve it please help me fix it.|||

Have you gotten anywhere with your problem?

This is what was found in our SQL Error logs: "Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b".

Our problem occurs from our weekly reboot - so we see the error toward the top of the log. This error seems to be occuring frequently on our servers lately. It is not only causing outage problems on our ADSI linked servers but we have a new implementation of an application that uses impersonation(Kerberos) from Web & Sharepoint servers to SQL Server that is about to go to production that recently shared in this problem also.

It seems to be due to the fact that MSDTC is not available when SQL Server starts. We are going to be trying a registry key fix to force a dependency that was recommended. We will see after this weekend.

|||

Just to follow-up:

It's been a month now and the fix seems to have worked. The originator of this thread had problems with SQL Server on Windows 2003. But in our systems, the servers affected are SQL Servers on Windows 2000 only, both SQL Server 2000 and 2005.

Add the "MSDTC" to the registry to force SQL Server to be dependent on MSDTC service (where MSSQL is the default instance):

Key: [HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSSQL]

Value Name: DependOnService

Value Type : REG_MULTI_SZ

Value: MSDTC

|||

Almost the whole issue is syntax related.

Linking SQL Server to Active Directory is tricky. and Microsoft support/help isn't very intuitive for this.
Check a few things first...
1. two single quotes not double.
2. Make connection w/out security context.


Follow this syntax:
EXEC master.dbo.sp_addlinkedserver @.server = N'ADSI',
@.srvproduct=N'Active Directory Services', @.provider=N'ADsDSOObject',
@.datasrc=N'Servername.domain.com' --AKA the full computer name of the AD server

Then execute the openquery like this:

select * from openquery
(
ADSI,'SELECT name
FROM ''LDAP://Servername.domain.com''
WHERE objectCategory = ''Person'' AND objectClass = ''user''
')

|||

Hi,

Not sure if this is the correct forum but I also need some help on a similar matter. I have connected my Sharpoint Server to ADAM and imported the users and groups into Sharepoint, however I want to display some SQL 2005 data in a web part, how can I get the ADAM user to be recognized by SQL 2005 using the current logged in Sharepoint (ADAM) User.

Jos

Active Directory/ADSI connection problems...help!

I am having weird problems using ADSI and SQL Server. Our local intranet is ASP with a SQL database on Windows 2003 Server. It uses Active Directory (via ADSI linked server) to get authenicate users, etc.

Every now and then (about once a month) the SQL connection to AD will "crash". The following error is what I see when it has crashed:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB error trace [OLE/DB Provider 'ADSDSOObject' ICommandText::Execute returned 0x80040e37].

Sometimes it will come back on its own later, others are solved by a server reboot. Here is how my SQL query looks:

SELECT adspath
FROM OPENQUERY(ADSI,
'<LDAP://DC=servername,DC=net>;(&(objectCategory=Person)(objectClass=user));adspath;subtree')
Rowset_1
WHERE (sn <> '')

Where can I start to get to the bottom of this?Anyone?|||

Is your issue resolved?

Thanks

|||I have the same problem, please if you solve it please help me fix it.|||

Have you gotten anywhere with your problem?

This is what was found in our SQL Error logs: "Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b".

Our problem occurs from our weekly reboot - so we see the error toward the top of the log. This error seems to be occuring frequently on our servers lately. It is not only causing outage problems on our ADSI linked servers but we have a new implementation of an application that uses impersonation(Kerberos) from Web & Sharepoint servers to SQL Server that is about to go to production that recently shared in this problem also.

It seems to be due to the fact that MSDTC is not available when SQL Server starts. We are going to be trying a registry key fix to force a dependency that was recommended. We will see after this weekend.

|||

Just to follow-up:

It's been a month now and the fix seems to have worked. The originator of this thread had problems with SQL Server on Windows 2003. But in our systems, the servers affected are SQL Servers on Windows 2000 only, both SQL Server 2000 and 2005.

Add the "MSDTC" to the registry to force SQL Server to be dependent on MSDTC service (where MSSQL is the default instance):

Key: [HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSSQL]

Value Name: DependOnService

Value Type : REG_MULTI_SZ

Value: MSDTC

|||

Almost the whole issue is syntax related.

Linking SQL Server to Active Directory is tricky. and Microsoft support/help isn't very intuitive for this.
Check a few things first...
1. two single quotes not double.
2. Make connection w/out security context.


Follow this syntax:
EXEC master.dbo.sp_addlinkedserver @.server = N'ADSI',
@.srvproduct=N'Active Directory Services', @.provider=N'ADsDSOObject',
@.datasrc=N'Servername.domain.com' --AKA the full computer name of the AD server

Then execute the openquery like this:

select * from openquery
(
ADSI,'SELECT name
FROM ''LDAP://Servername.domain.com''
WHERE objectCategory = ''Person'' AND objectClass = ''user''
')

Monday, March 19, 2012

Active Directory/ADSI connection problems...help!

I am having weird problems using ADSI and SQL Server. Our local intranet is ASP with a SQL database on Windows 2003 Server. It uses Active Directory (via ADSI linked server) to get authenicate users, etc.

Every now and then (about once a month) the SQL connection to AD will "crash". The following error is what I see when it has crashed:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB error trace [OLE/DB Provider 'ADSDSOObject' ICommandText::Execute returned 0x80040e37].

Sometimes it will come back on its own later, others are solved by a server reboot. Here is how my SQL query looks:

SELECT adspath
FROM OPENQUERY(ADSI,
'<LDAP://DC=servername,DC=net>;(&(objectCategory=Person)(objectClass=user));adspath;subtree')
Rowset_1
WHERE (sn <> '')

Where can I start to get to the bottom of this?Anyone?|||

Is your issue resolved?

Thanks

|||I have the same problem, please if you solve it please help me fix it.|||

Have you gotten anywhere with your problem?

This is what was found in our SQL Error logs: "Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b".

Our problem occurs from our weekly reboot - so we see the error toward the top of the log. This error seems to be occuring frequently on our servers lately. It is not only causing outage problems on our ADSI linked servers but we have a new implementation of an application that uses impersonation(Kerberos) from Web & Sharepoint servers to SQL Server that is about to go to production that recently shared in this problem also.

It seems to be due to the fact that MSDTC is not available when SQL Server starts. We are going to be trying a registry key fix to force a dependency that was recommended. We will see after this weekend.

|||

Just to follow-up:

It's been a month now and the fix seems to have worked. The originator of this thread had problems with SQL Server on Windows 2003. But in our systems, the servers affected are SQL Servers on Windows 2000 only, both SQL Server 2000 and 2005.

Add the "MSDTC" to the registry to force SQL Server to be dependent on MSDTC service (where MSSQL is the default instance):

Key: [HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSSQL]

Value Name: DependOnService

Value Type : REG_MULTI_SZ

Value: MSDTC

|||

Almost the whole issue is syntax related.

Linking SQL Server to Active Directory is tricky. and Microsoft support/help isn't very intuitive for this.
Check a few things first...
1. two single quotes not double.
2. Make connection w/out security context.


Follow this syntax:
EXEC master.dbo.sp_addlinkedserver @.server = N'ADSI',
@.srvproduct=N'Active Directory Services', @.provider=N'ADsDSOObject',
@.datasrc=N'Servername.domain.com' --AKA the full computer name of the AD server

Then execute the openquery like this:

select * from openquery
(
ADSI,'SELECT name
FROM ''LDAP://Servername.domain.com''
WHERE objectCategory = ''Person'' AND objectClass = ''user''
')

Active Directory Domain Local Groups

Hi,
I have the following problem with AD an RS: when creating a group of users
as a "domain local group" in AD, i'm able to give a specific item-level role
in RS to members of this group. But it looks like rights are not effective
for those users. For example if the group is defined as "reader" on a folder,
group members can't see it in RS!
Everything works fine when the created group is a "global group" in AD.
Thanx in advance.
Greg.I still need help.
Thanx in advance.
"Greg - NEOS" wrote:
> Hi,
> I have the following problem with AD an RS: when creating a group of users
> as a "domain local group" in AD, i'm able to give a specific item-level role
> in RS to members of this group. But it looks like rights are not effective
> for those users. For example if the group is defined as "reader" on a folder,
> group members can't see it in RS!
> Everything works fine when the created group is a "global group" in AD.
> Thanx in advance.
> Greg.

Active Directory Conversion

We are updating an NT domain to Active Directory.
All of our security group within RS are based on local (machine groups)
which contain domain groups as members. So we are pretty comfortable with
the conversion path required there.
We understand how we can change the Data Base Agent and Remote Execution
Agents using rsconfig (-c and -e switches).
The ReportServer Service runs as NT Authority\Network Service and as such
needs no change.
Is there anything else we are missing which must be touched to get to AD?
thanks in advance,
dlrDennis,
My company recently migrated all the users from an NT domain to an AD domain
and since we have been unable to setup new email subscriptions through RS.
Our work around has been to login to the old domain and create the
subscriptions. It seems that the account RS uses does not have permissions to
read the TGGAU attribute on the user account that was used to create and to
process the e-mail subscriptions. Until our RS server is migrated over to the
new AD domain I don't know of a solution to this issue. You can find out more
about it below...hope this helps...
http://support.microsoft.com/default.aspx?scid=kb;en-us;842423
Regards,
Ben Sullins
"Dennis Redfield" wrote:
> We are updating an NT domain to Active Directory.
> All of our security group within RS are based on local (machine groups)
> which contain domain groups as members. So we are pretty comfortable with
> the conversion path required there.
> We understand how we can change the Data Base Agent and Remote Execution
> Agents using rsconfig (-c and -e switches).
> The ReportServer Service runs as NT Authority\Network Service and as such
> needs no change.
> Is there anything else we are missing which must be touched to get to AD?
>
> thanks in advance,
> dlr
>
>|||thanx
"Ben Sullins" <BenSullins@.discussions.microsoft.com> wrote in message
news:5471A631-EA2F-4661-843B-2374D548F7A5@.microsoft.com...
> Dennis,
> My company recently migrated all the users from an NT domain to an AD
domain
> and since we have been unable to setup new email subscriptions through RS.
> Our work around has been to login to the old domain and create the
> subscriptions. It seems that the account RS uses does not have permissions
to
> read the TGGAU attribute on the user account that was used to create and
to
> process the e-mail subscriptions. Until our RS server is migrated over to
the
> new AD domain I don't know of a solution to this issue. You can find out
more
> about it below...hope this helps...
> http://support.microsoft.com/default.aspx?scid=kb;en-us;842423
> Regards,
> Ben Sullins
> "Dennis Redfield" wrote:
> > We are updating an NT domain to Active Directory.
> > All of our security group within RS are based on local (machine groups)
> > which contain domain groups as members. So we are pretty comfortable
with
> > the conversion path required there.
> > We understand how we can change the Data Base Agent and Remote Execution
> > Agents using rsconfig (-c and -e switches).
> > The ReportServer Service runs as NT Authority\Network Service and as
such
> > needs no change.
> >
> > Is there anything else we are missing which must be touched to get to
AD?
> >
> >
> > thanks in advance,
> >
> > dlr
> >
> >
> >
> >

Tuesday, March 6, 2012

ack message not picked up by stored procs

Hi

I setup a message between 2 database on a local instance. The message is send to the target and the target did send a reply. However, the reply is not picked up by the initiator. I did a try but there was nothing telling me why it did not pick up the reply. there is nothing in the textdata of the brokerclassify event. I query the queue on the initiator, the message is there, but the stored proc attached to the queue is not doing anything it seems. What else can I check here,

thanks

P

If you're positive the reply is in the initiator's queue but activation does not kick in, I'd look at the following:
- activation is not turned on. Check the is_activation_enabled column of sys.service_queues. If is 0, ALTER QUEUE <queueName> WITH ACTIVATION (STATUS = ON);
- the procedure has a bug and it runs, but has no effects. Check in Profiler if the Broker:Activation (Strat/Stop) events are being traced.

HTH,
~ Remus

account used to run SQL Server services

I'm attempting to follow the best practice of running the SQL Server
services under a local windows account with "just enough priviledges"
without assigning it as an admin. I've read numerous places to not use the
Local System Account as well.
In Books Online, the section titled "Troubleshooting MSSQLServer or
SQLServerAgent Services User Accounts" has the list of rights the account
must have to make the services work. Is there a utility that you can point
at a local windows account, and it will assign the appropriate rights for
you? I missed my opportunity to do this when installing SQL Server
initially.
Thanks in advance.
MarkI don't know of a utilty.
You may find these links helpful:
http://whidbey.msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_overview_6k1f.asp
http://whidbey.msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_afterinstall_4p0z.asp
--
Keith
"Mark" <field027@.idonotlikejunkmail.umn.edu> wrote in message
news:%238GNYFk$EHA.3924@.TK2MSFTNGP15.phx.gbl...
> I'm attempting to follow the best practice of running the SQL Server
> services under a local windows account with "just enough priviledges"
> without assigning it as an admin. I've read numerous places to not use
the
> Local System Account as well.
> In Books Online, the section titled "Troubleshooting MSSQLServer or
> SQLServerAgent Services User Accounts" has the list of rights the account
> must have to make the services work. Is there a utility that you can
point
> at a local windows account, and it will assign the appropriate rights for
> you? I missed my opportunity to do this when installing SQL Server
> initially.
> Thanks in advance.
> Mark
>

account used to run SQL Server services

I'm attempting to follow the best practice of running the SQL Server
services under a local windows account with "just enough priviledges"
without assigning it as an admin. I've read numerous places to not use the
Local System Account as well.
In Books Online, the section titled "Troubleshooting MSSQLServer or
SQLServerAgent Services User Accounts" has the list of rights the account
must have to make the services work. Is there a utility that you can point
at a local windows account, and it will assign the appropriate rights for
you? I missed my opportunity to do this when installing SQL Server
initially.
Thanks in advance.
Mark
I don't know of a utilty.
You may find these links helpful:
http://whidbey.msdn.microsoft.com/li...rview_6k1f.asp
http://whidbey.msdn.microsoft.com/li...stall_4p0z.asp
Keith
"Mark" <field027@.idonotlikejunkmail.umn.edu> wrote in message
news:%238GNYFk$EHA.3924@.TK2MSFTNGP15.phx.gbl...
> I'm attempting to follow the best practice of running the SQL Server
> services under a local windows account with "just enough priviledges"
> without assigning it as an admin. I've read numerous places to not use
the
> Local System Account as well.
> In Books Online, the section titled "Troubleshooting MSSQLServer or
> SQLServerAgent Services User Accounts" has the list of rights the account
> must have to make the services work. Is there a utility that you can
point
> at a local windows account, and it will assign the appropriate rights for
> you? I missed my opportunity to do this when installing SQL Server
> initially.
> Thanks in advance.
> Mark
>

Saturday, February 25, 2012

account used to run SQL Server services

I'm attempting to follow the best practice of running the SQL Server
services under a local windows account with "just enough priviledges"
without assigning it as an admin. I've read numerous places to not use the
Local System Account as well.
In Books Online, the section titled "Troubleshooting MSSQLServer or
SQLServerAgent Services User Accounts" has the list of rights the account
must have to make the services work. Is there a utility that you can point
at a local windows account, and it will assign the appropriate rights for
you? I missed my opportunity to do this when installing SQL Server
initially.
Thanks in advance.
MarkI don't know of a utilty.
You may find these links helpful:
http://whidbey.msdn.microsoft.com/l...erview_6k1f.asp
http://whidbey.msdn.microsoft.com/l...nstall_4p0z.asp
Keith
"Mark" <field027@.idonotlikejunkmail.umn.edu> wrote in message
news:%238GNYFk$EHA.3924@.TK2MSFTNGP15.phx.gbl...
> I'm attempting to follow the best practice of running the SQL Server
> services under a local windows account with "just enough priviledges"
> without assigning it as an admin. I've read numerous places to not use
the
> Local System Account as well.
> In Books Online, the section titled "Troubleshooting MSSQLServer or
> SQLServerAgent Services User Accounts" has the list of rights the account
> must have to make the services work. Is there a utility that you can
point
> at a local windows account, and it will assign the appropriate rights for
> you? I missed my opportunity to do this when installing SQL Server
> initially.
> Thanks in advance.
> Mark
>

Account to Run SQL under?

Currently, our network/server/domain admins have admin control of our sql
servers. One manager wants to run sql under a special local admin account
to restrict this access, but then we will be effected by the password change
requirement, which could break sql every 90 days.
What is the best way to run sql so that the server admins don't have sql
admin access? Can I run it under "local system", and restrict machine
admins?Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>|||First of all, it is imposible to stop God from having access. And, in the
domain, Domain Administrators are God. However, you can slow them down
quite a bit. Here is a KB that details the procedures. Also know that if
you use AD Global Groups to grant the SQL Server DBAs administrative access,
which is a Best Practice, all the Domain Admin has to do is add themself or
the Domain Admins group to yours.
How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/kb/263712/EN-US/
How to change the SQL Server or SQL Server Agent Service account without
using SQL Enterprise Manager in SQL Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;283811
If you suspect foul play, it would be better to run some sort of Audit
Logging on your system and then once captured, bring it the attention of the
Data Center Director's attention. Keep in mind that just like the DBAs,
with great power comes great responsibility. No one should be placed in a
role that they are not qualified, and responsible for, to perform.
Just like the DBAs have the authority to delete every user/system database,
the responsibility is to preserve that data. It is no different for the
Domain Admins. They have the authority to disrupt operations but the
responsibility to preserve them. If you find an individual, or team, that
does not play by these rules, that must be made know to the Operations
Manager, regardless of the title or the position of the offender.
Sincerely,
Anthony Thomas
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:05b901c51b4e$87a454e0$a501280a@.phx.gbl...
Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>

Account to Run SQL under?

Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein

>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>
First of all, it is imposible to stop God from having access. And, in the
domain, Domain Administrators are God. However, you can slow them down
quite a bit. Here is a KB that details the procedures. Also know that if
you use AD Global Groups to grant the SQL Server DBAs administrative access,
which is a Best Practice, all the Domain Admin has to do is add themself or
the Domain Admins group to yours.
How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/kb/263712/EN-US/
How to change the SQL Server or SQL Server Agent Service account without
using SQL Enterprise Manager in SQL Server 2000
http://support.microsoft.com/default...b;en-us;283811
If you suspect foul play, it would be better to run some sort of Audit
Logging on your system and then once captured, bring it the attention of the
Data Center Director's attention. Keep in mind that just like the DBAs,
with great power comes great responsibility. No one should be placed in a
role that they are not qualified, and responsible for, to perform.
Just like the DBAs have the authority to delete every user/system database,
the responsibility is to preserve that data. It is no different for the
Domain Admins. They have the authority to disrupt operations but the
responsibility to preserve them. If you find an individual, or team, that
does not play by these rules, that must be made know to the Operations
Manager, regardless of the title or the position of the offender.
Sincerely,
Anthony Thomas

"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:05b901c51b4e$87a454e0$a501280a@.phx.gbl...
Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein

>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>

Account to Run SQL under?

Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein

>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>First of all, it is imposible to stop God from having access. And, in the
domain, Domain Administrators are God. However, you can slow them down
quite a bit. Here is a KB that details the procedures. Also know that if
you use AD Global Groups to grant the SQL Server DBAs administrative access,
which is a Best Practice, all the Domain Admin has to do is add themself or
the Domain Admins group to yours.
How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/kb/263712/EN-US/
How to change the SQL Server or SQL Server Agent Service account without
using SQL Enterprise Manager in SQL Server 2000
http://support.microsoft.com/defaul...kb;en-us;283811
If you suspect foul play, it would be better to run some sort of Audit
Logging on your system and then once captured, bring it the attention of the
Data Center Director's attention. Keep in mind that just like the DBAs,
with great power comes great responsibility. No one should be placed in a
role that they are not qualified, and responsible for, to perform.
Just like the DBAs have the authority to delete every user/system database,
the responsibility is to preserve that data. It is no different for the
Domain Admins. They have the authority to disrupt operations but the
responsibility to preserve them. If you find an individual, or team, that
does not play by these rules, that must be made know to the Operations
Manager, regardless of the title or the position of the offender.
Sincerely,
Anthony Thomas
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:05b901c51b4e$87a454e0$a501280a@.phx.gbl...
Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein

>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>

accing to shered volumes

Roy Goldhammer wrote:
> Hello there
> I have local hard drive, which i can easy run xp_cmdshell 'dir c:'
> On the same computer i have shered Z: volume which is hard drive on anothe
r
> server
> How can i get list of all files on z by using xp_cmdshell 'dir z:' ?
>
xp_cmdshell '\\servername\sharename'
The mapping to drive Z: only exists under your login, not under the
login that the SQL Server service runs under. You also need to make
sure that the SQL Server service account has access to the share.Hello there
I have local hard drive, which i can easy run xp_cmdshell 'dir c:\'
On the same computer i have shered Z: volume which is hard drive on another
server
How can i get list of all files on z by using xp_cmdshell 'dir z:' ?|||Roy Goldhammer wrote:
> Hello there
> I have local hard drive, which i can easy run xp_cmdshell 'dir c:'
> On the same computer i have shered Z: volume which is hard drive on anothe
r
> server
> How can i get list of all files on z by using xp_cmdshell 'dir z:' ?
>
xp_cmdshell '\\servername\sharename'
The mapping to drive Z: only exists under your login, not under the
login that the SQL Server service runs under. You also need to make
sure that the SQL Server service account has access to the share.

accing to shered volumes

Hello there
I have local hard drive, which i can easy run xp_cmdshell 'dir c:\'
On the same computer i have shered Z: volume which is hard drive on another
server
How can i get list of all files on z by using xp_cmdshell 'dir z:' ?Roy Goldhammer wrote:
> Hello there
> I have local hard drive, which i can easy run xp_cmdshell 'dir c:\'
> On the same computer i have shered Z: volume which is hard drive on another
> server
> How can i get list of all files on z by using xp_cmdshell 'dir z:' ?
>
xp_cmdshell '\\servername\sharename'
The mapping to drive Z: only exists under your login, not under the
login that the SQL Server service runs under. You also need to make
sure that the SQL Server service account has access to the share.

accing shered volume

Hello there
I have local hard drive, which i can easy run xp_cmdshell 'dir c:\'
On the same computer i have shered Z: volume which is hard drive on another
server
How can i get list of all files on z by using xp_cmdshell 'dir z:' ?What account is SQL Server running as? It must have permissions to the Z:\
(typically this means you must set up SQLServer to run as a Domain\User as
opposed to a local user or built-in account).
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:eXbwFn7kGHA.3816@.TK2MSFTNGP02.phx.gbl...
> Hello there
> I have local hard drive, which i can easy run xp_cmdshell 'dir c:'
> On the same computer i have shered Z: volume which is hard drive on
> another
> server
> How can i get list of all files on z by using xp_cmdshell 'dir z:' ?
>
>

accidentally deleted a table in my local SQL Server how can I get back the table

Hi,

I accidentally deleted a table in my local server. How can I get back the table? I did not do it as a transaction!

Thanks in AdvanceYou need to restore back from your backup if available. There may be third party softwares that allow you to do such operations ...

Sunday, February 19, 2012

Accessing SQL2K on the net from local pc

Hi, i'm new to SQL2K. I see in my connect string (ASP) a IP-address. I can
choose between a public or a internal IP.
If i use the public IP, where can i find examples on how to query the
database from a local pc in a Visual Basic 6 program ? Or is this not
possible?
Grard.Hi
You should consult your network administrator for the correct IP address to
use. It is quite possible that there are several NICs on the database and we
b
servers.
John
"Gérard Leclercq" wrote:

> Hi, i'm new to SQL2K. I see in my connect string (ASP) a IP-address. I can
> choose between a public or a internal IP.
> If i use the public IP, where can i find examples on how to query the
> database from a local pc in a Visual Basic 6 program ? Or is this not
> possible?
> Gérard.
>
>|||I ask if its possible, not which IP to use. And if its possible, some
examples.
Grad.|||Hi
If you are looking for example connection string try
http://www.connectionstrings.com/ or
http://www.carlprothman.net/Default.aspx?tabid=81
John
"Gérard Leclercq" wrote:

> I ask if its possible, not which IP to use. And if its possible, some
> examples.
> Gérad.
>
>

Monday, February 13, 2012

Accessing Reports on local LAN

Hi,

My reports are deployed on reporting server installed on my machine. Now i want to access the reports on other machines which are on local LAN along with my machine. When i try to access reports from some other machine browser gives error page not found.

Can any one tell me how to do this.

Thanks in advance..

If you can put in what the error is and what type of servers you are running from then we can try and help!

Is your SQL seperate?

Did you enter //servername/reports and try and add it in here?

Have you set up permission to access the server!?

|||

Hey i got the solution.....

First thing is ur Server has to be on domain and not a workgroup computer.

Second thing is you will have to give acess rights to the users u want to see the reports.

Cheers

Siddharth...