Showing posts with label directory. Show all posts
Showing posts with label directory. Show all posts

Saturday, February 25, 2012

cmdexec in SQL agent Jobs

If I do xp_cmdexec 'dir' it displays the directory:
C:\Program Files\Common Files\System\Mapi\1033\NT
on a different sql server the same command shows the directory:
C:\WINNT\system32
How do you set the directory which xp_cmdexec uses?My guess is that it uses the PATH environment variable. You should be able to check that from a DOS
box:
SET
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"AR" <remove_rittingAThot_mail_DOT_C_O_M> wrote in message
news:uRZPa2erDHA.3504@.TK2MSFTNGP11.phx.gbl...
> If I do xp_cmdexec 'dir' it displays the directory:
> C:\Program Files\Common Files\System\Mapi\1033\NT
> on a different sql server the same command shows the directory:
> C:\WINNT\system32
> How do you set the directory which xp_cmdexec uses?
>
>

ClusterService Log On Account and SQL2000

It is my understanding that this Active Directory account takes on the
role(s) of SQL's BuiltIn Administrator in a clustered environment.
Should the ClusterService Log On account password be reset in AD, without
reseting in the properties tab for the service on the physical nodes cluster
fail overs can still occur because the ClusterService has already been
started. BUT, what activity in SQL2000 could the AD account be doing on
behalf of the SQL BuiltIn Administrator account that would affect the
cluster and initiate a failover if it could not authenticate on the Domain?
Dave
That is not right. By default (God, I hate Microsoft's defaults), the
Cluster Service MUST BE a member of the Local Administrators group on each
cluster node, by which it gains access to the SQL Server installations
through the default BUILTIN\Administrators membership to the SQL Server
system admin default server role.
If you follow the security best practices, and you should, you will remove
the BUILTIN\Administrators group for the installation; however, the Cluster
Service account will still need access to run the resource monitor "Is
Alive" check, which, in the case for the SQL Server resource, is nothing but
the SELECT @.@.SERVERNAME query; thus, the Cluster Service account merely
needs access to the installation, but no special rights beyond this, as the
guest database user in the master database has permissions to execute this
query.
Sincerely,
Anthony Thomas

"David Currie" <decurrie@.rogers.com> wrote in message
news:%23aT3qmQBHHA.204@.TK2MSFTNGP04.phx.gbl...
> It is my understanding that this Active Directory account takes on the
> role(s) of SQL's BuiltIn Administrator in a clustered environment.
> Should the ClusterService Log On account password be reset in AD, without
> reseting in the properties tab for the service on the physical nodes
cluster
> fail overs can still occur because the ClusterService has already been
> started. BUT, what activity in SQL2000 could the AD account be doing on
> behalf of the SQL BuiltIn Administrator account that would affect the
> cluster and initiate a failover if it could not authenticate on the
Domain?
> Dave
>

Tuesday, February 14, 2012

Clustered sql binn directory

Hi I do not have any experience of clustered servers
I have some software that needs some dll's placed into the directory below
which an extended strored proc uses to verify and run internal code.
C:\Program Files\Microsoft SQL Server\MSSQL<instancename>\Binn
this works perfect on single Sql server instances or named instances
If two servers are set as clustered and both are active. Does anyone know
how the structure of the sql binn directories are laid out. If I have an
extened proc that checks a dll in the sql instance binn directory where or
how is this named for clustered servers.
Or has anyone used extended procs with clustered servers?
thanks for any advice
Sammy
I use extended stored procedures with clustered SQL regularly. The SQL
clustered and non-clustered binary structure is exactly the same. They only
difference is the structure is paralleled on each node. Therefore, you have
to place the appropriate DLL in the same directory on all the nodes.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Sammy" <Sammy@.discussions.microsoft.com> wrote in message
news:EF42B68E-1D9B-4D2C-91D7-74273953E5CD@.microsoft.com...
> Hi I do not have any experience of clustered servers
> I have some software that needs some dll's placed into the directory
> below
> which an extended strored proc uses to verify and run internal code.
> C:\Program Files\Microsoft SQL Server\MSSQL<instancename>\Binn
> this works perfect on single Sql server instances or named instances
>
> If two servers are set as clustered and both are active. Does anyone know
> how the structure of the sql binn directories are laid out. If I have an
> extened proc that checks a dll in the sql instance binn directory where or
> how is this named for clustered servers.
> Or has anyone used extended procs with clustered servers?
> thanks for any advice
> Sammy
>
>
>
>