looks like a noob question but how can i manage msde2000...i can see sql is runnin but how can i create database , attach/detach database, write functions and so on...
thanx alot for the reply :)Originally posted by Schuldiner
looks like a noob question but how can i manage msde2000...i can see sql is runnin but how can i create database , attach/detach database, write functions and so on...
thanx alot for the reply :)
msde does not come with tools like EM or QA but there are some tools available for database management in msde to name a few by microsoft are SQL Server Web Data Administrator SQL Server Web Data Administrator (http://www.microsoft.com/downloads/details.aspx?familyid=c039a798-c57a-419e-acbc-2a332cb7f959&displaylang=en) and OSQL
for more info in detail check:
http://www.aspfaq.com/show.asp?id=2442|||thank u very much :)
Showing posts with label manage. Show all posts
Showing posts with label manage. Show all posts
Friday, March 23, 2012
Monday, March 12, 2012
Non sa running jobs?
Is there a way for a user to manage ( run, delete, add ) a job if he has not
got sa permission?
Thanks
AlexAlex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note howev
er
> that membership of this role should be limited as the role enables a user
to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>
>|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the passwor
d
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy
.
HTH, mary
"Alex" wrote:
[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's hav
e
> been stripped off sa/SYSADMIN fixed role permission so we can't modify dat
a.
> The side effect of this is that there are loads of admin tasks we cannot n
ow
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>|||Curious, if the is a reason to suddenly restore a db in the middle of the da
y
so production activities can resume, is the same process to log in as SA
required?
ChrisR
"Alex" wrote:
[vbcol=seagreen]
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off fro
m
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
>|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
[vbcol=seagreen]
> Since we don't want SA running jobs (or being in the Sysadmin group), I se
t
> up a login with win authent, sysadmin to run jobs. No one needs the passw
ord
> to use; just set this user up as the proxy account (under agent properties
,
> job system), and if any job owner is not a sysadmin, it defaults to this g
uy.
> HTH, mary
> "Alex" wrote:
>|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 wi
ll
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
got sa permission?
Thanks
AlexAlex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note howev
er
> that membership of this role should be limited as the role enables a user
to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>
>|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the passwor
d
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy
.
HTH, mary
"Alex" wrote:
[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's hav
e
> been stripped off sa/SYSADMIN fixed role permission so we can't modify dat
a.
> The side effect of this is that there are loads of admin tasks we cannot n
ow
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>|||Curious, if the is a reason to suddenly restore a db in the middle of the da
y
so production activities can resume, is the same process to log in as SA
required?
ChrisR
"Alex" wrote:
[vbcol=seagreen]
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off fro
m
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
>|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
[vbcol=seagreen]
> Since we don't want SA running jobs (or being in the Sysadmin group), I se
t
> up a login with win authent, sysadmin to run jobs. No one needs the passw
ord
> to use; just set this user up as the proxy account (under agent properties
,
> job system), and if any job owner is not a sysadmin, it defaults to this g
uy.
> HTH, mary
> "Alex" wrote:
>|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 wi
ll
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
Non sa running jobs?
Is there a way for a user to manage ( run, delete, add ) a job if he has not
got sa permission?
Thanks
AlexAlex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note however
> that membership of this role should be limited as the role enables a user to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > not
> > got sa permission?
> >
> > Thanks
> >
> > Alex
>
>|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>> Alex,
>> Yes if the user is a member of the SYSADMIN fixed server role. Note
>> however
>> that membership of this role should be limited as the role enables a user
>> to
>> do pretty much anything in SQL Server.
>> HTH
>> Jerry
>> "Alex" <Alex@.discussions.microsoft.com> wrote in message
>> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>> > Is there a way for a user to manage ( run, delete, add ) a job if he
>> > has
>> > not
>> > got sa permission?
>> >
>> > Thanks
>> >
>> > Alex
>>|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the password
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy.
HTH, mary
"Alex" wrote:
> Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> The side effect of this is that there are loads of admin tasks we cannot now
> do.
> Alex
>
> "Jerry Spivey" wrote:
> > Alex,
> >
> > Yes if the user is a member of the SYSADMIN fixed server role. Note however
> > that membership of this role should be limited as the role enables a user to
> > do pretty much anything in SQL Server.
> >
> > HTH
> >
> > Jerry
> > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > > not
> > > got sa permission?
> > >
> > > Thanks
> > >
> > > Alex
> >
> >
> >|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > data.
> > The side effect of this is that there are loads of admin tasks we cannot
> > now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> >> Alex,
> >>
> >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> >> however
> >> that membership of this role should be limited as the role enables a user
> >> to
> >> do pretty much anything in SQL Server.
> >>
> >> HTH
> >>
> >> Jerry
> >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> >> > has
> >> > not
> >> > got sa permission?
> >> >
> >> > Thanks
> >> >
> >> > Alex
> >>
> >>
> >>
>
>|||Curious, if the is a reason to suddenly restore a db in the middle of the day
so production activities can resume, is the same process to log in as SA
required?
--
ChrisR
"Alex" wrote:
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off from
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
> > Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> > the SYSADMIN fixed server role? How can you do your job?
> > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > > have
> > > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > > data.
> > > The side effect of this is that there are loads of admin tasks we cannot
> > > now
> > > do.
> > >
> > > Alex
> > >
> > >
> > > "Jerry Spivey" wrote:
> > >
> > >> Alex,
> > >>
> > >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> > >> however
> > >> that membership of this role should be limited as the role enables a user
> > >> to
> > >> do pretty much anything in SQL Server.
> > >>
> > >> HTH
> > >>
> > >> Jerry
> > >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> > >> > has
> > >> > not
> > >> > got sa permission?
> > >> >
> > >> > Thanks
> > >> >
> > >> > Alex
> > >>
> > >>
> > >>
> >
> >
> >|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
--
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>> Alex,
>> Yes if the user is a member of the SYSADMIN fixed server role. Note
>> however
>> that membership of this role should be limited as the role enables a user
>> to
>> do pretty much anything in SQL Server.
>> HTH
>> Jerry
>> "Alex" <Alex@.discussions.microsoft.com> wrote in message
>> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>> > Is there a way for a user to manage ( run, delete, add ) a job if he
>> > has
>> > not
>> > got sa permission?
>> >
>> > Thanks
>> >
>> > Alex
>>|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
> Since we don't want SA running jobs (or being in the Sysadmin group), I set
> up a login with win authent, sysadmin to run jobs. No one needs the password
> to use; just set this user up as the proxy account (under agent properties,
> job system), and if any job owner is not a sysadmin, it defaults to this guy.
> HTH, mary
> "Alex" wrote:
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> > The side effect of this is that there are loads of admin tasks we cannot now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> > > Alex,
> > >
> > > Yes if the user is a member of the SYSADMIN fixed server role. Note however
> > > that membership of this role should be limited as the role enables a user to
> > > do pretty much anything in SQL Server.
> > >
> > > HTH
> > >
> > > Jerry
> > > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > > news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > > > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > > > not
> > > > got sa permission?
> > > >
> > > > Thanks
> > > >
> > > > Alex
> > >
> > >
> > >|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 will
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > data.
> > The side effect of this is that there are loads of admin tasks we cannot
> > now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> >> Alex,
> >>
> >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> >> however
> >> that membership of this role should be limited as the role enables a user
> >> to
> >> do pretty much anything in SQL Server.
> >>
> >> HTH
> >>
> >> Jerry
> >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> >> > has
> >> > not
> >> > got sa permission?
> >> >
> >> > Thanks
> >> >
> >> > Alex
> >>
> >>
> >>
>
>
got sa permission?
Thanks
AlexAlex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note however
> that membership of this role should be limited as the role enables a user to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > not
> > got sa permission?
> >
> > Thanks
> >
> > Alex
>
>|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>> Alex,
>> Yes if the user is a member of the SYSADMIN fixed server role. Note
>> however
>> that membership of this role should be limited as the role enables a user
>> to
>> do pretty much anything in SQL Server.
>> HTH
>> Jerry
>> "Alex" <Alex@.discussions.microsoft.com> wrote in message
>> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>> > Is there a way for a user to manage ( run, delete, add ) a job if he
>> > has
>> > not
>> > got sa permission?
>> >
>> > Thanks
>> >
>> > Alex
>>|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the password
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy.
HTH, mary
"Alex" wrote:
> Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> The side effect of this is that there are loads of admin tasks we cannot now
> do.
> Alex
>
> "Jerry Spivey" wrote:
> > Alex,
> >
> > Yes if the user is a member of the SYSADMIN fixed server role. Note however
> > that membership of this role should be limited as the role enables a user to
> > do pretty much anything in SQL Server.
> >
> > HTH
> >
> > Jerry
> > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > > not
> > > got sa permission?
> > >
> > > Thanks
> > >
> > > Alex
> >
> >
> >|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > data.
> > The side effect of this is that there are loads of admin tasks we cannot
> > now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> >> Alex,
> >>
> >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> >> however
> >> that membership of this role should be limited as the role enables a user
> >> to
> >> do pretty much anything in SQL Server.
> >>
> >> HTH
> >>
> >> Jerry
> >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> >> > has
> >> > not
> >> > got sa permission?
> >> >
> >> > Thanks
> >> >
> >> > Alex
> >>
> >>
> >>
>
>|||Curious, if the is a reason to suddenly restore a db in the middle of the day
so production activities can resume, is the same process to log in as SA
required?
--
ChrisR
"Alex" wrote:
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off from
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
> > Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> > the SYSADMIN fixed server role? How can you do your job?
> > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > > have
> > > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > > data.
> > > The side effect of this is that there are loads of admin tasks we cannot
> > > now
> > > do.
> > >
> > > Alex
> > >
> > >
> > > "Jerry Spivey" wrote:
> > >
> > >> Alex,
> > >>
> > >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> > >> however
> > >> that membership of this role should be limited as the role enables a user
> > >> to
> > >> do pretty much anything in SQL Server.
> > >>
> > >> HTH
> > >>
> > >> Jerry
> > >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> > >> > has
> > >> > not
> > >> > got sa permission?
> > >> >
> > >> > Thanks
> > >> >
> > >> > Alex
> > >>
> > >>
> > >>
> >
> >
> >|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
--
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
>> Alex,
>> Yes if the user is a member of the SYSADMIN fixed server role. Note
>> however
>> that membership of this role should be limited as the role enables a user
>> to
>> do pretty much anything in SQL Server.
>> HTH
>> Jerry
>> "Alex" <Alex@.discussions.microsoft.com> wrote in message
>> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>> > Is there a way for a user to manage ( run, delete, add ) a job if he
>> > has
>> > not
>> > got sa permission?
>> >
>> > Thanks
>> >
>> > Alex
>>|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
> Since we don't want SA running jobs (or being in the Sysadmin group), I set
> up a login with win authent, sysadmin to run jobs. No one needs the password
> to use; just set this user up as the proxy account (under agent properties,
> job system), and if any job owner is not a sysadmin, it defaults to this guy.
> HTH, mary
> "Alex" wrote:
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> > The side effect of this is that there are loads of admin tasks we cannot now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> > > Alex,
> > >
> > > Yes if the user is a member of the SYSADMIN fixed server role. Note however
> > > that membership of this role should be limited as the role enables a user to
> > > do pretty much anything in SQL Server.
> > >
> > > HTH
> > >
> > > Jerry
> > > "Alex" <Alex@.discussions.microsoft.com> wrote in message
> > > news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> > > > Is there a way for a user to manage ( run, delete, add ) a job if he has
> > > > not
> > > > got sa permission?
> > > >
> > > > Thanks
> > > >
> > > > Alex
> > >
> > >
> > >|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 will
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
> > Thanks for this. But the problem we have is SOX compliance !. Us dba's
> > have
> > been stripped off sa/SYSADMIN fixed role permission so we can't modify
> > data.
> > The side effect of this is that there are loads of admin tasks we cannot
> > now
> > do.
> >
> > Alex
> >
> >
> > "Jerry Spivey" wrote:
> >
> >> Alex,
> >>
> >> Yes if the user is a member of the SYSADMIN fixed server role. Note
> >> however
> >> that membership of this role should be limited as the role enables a user
> >> to
> >> do pretty much anything in SQL Server.
> >>
> >> HTH
> >>
> >> Jerry
> >> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> >> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> >> > Is there a way for a user to manage ( run, delete, add ) a job if he
> >> > has
> >> > not
> >> > got sa permission?
> >> >
> >> > Thanks
> >> >
> >> > Alex
> >>
> >>
> >>
>
>
Non sa running jobs?
Is there a way for a user to manage ( run, delete, add ) a job if he has not
got sa permission?
Thanks
Alex
Alex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex
|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note however
> that membership of this role should be limited as the role enables a user to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>
>
|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the password
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy.
HTH, mary
"Alex" wrote:
[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> The side effect of this is that there are loads of admin tasks we cannot now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
|||Curious, if the is a reason to suddenly restore a db in the middle of the day
so production activities can resume, is the same process to log in as SA
required?
ChrisR
"Alex" wrote:
[vbcol=seagreen]
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off from
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
[vbcol=seagreen]
> Since we don't want SA running jobs (or being in the Sysadmin group), I set
> up a login with win authent, sysadmin to run jobs. No one needs the password
> to use; just set this user up as the proxy account (under agent properties,
> job system), and if any job owner is not a sysadmin, it defaults to this guy.
> HTH, mary
> "Alex" wrote:
|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 will
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
got sa permission?
Thanks
Alex
Alex,
Yes if the user is a member of the SYSADMIN fixed server role. Note however
that membership of this role should be limited as the role enables a user to
do pretty much anything in SQL Server.
HTH
Jerry
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
> Is there a way for a user to manage ( run, delete, add ) a job if he has
> not
> got sa permission?
> Thanks
> Alex
|||Thanks for this. But the problem we have is SOX compliance !. Us dba's have
been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
The side effect of this is that there are loads of admin tasks we cannot now
do.
Alex
"Jerry Spivey" wrote:
> Alex,
> Yes if the user is a member of the SYSADMIN fixed server role. Note however
> that membership of this role should be limited as the role enables a user to
> do pretty much anything in SQL Server.
> HTH
> Jerry
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:3CD1CB0F-42E8-4DA9-A04C-CBD6AE4845CB@.microsoft.com...
>
>
|||Hmmm...that doesn't sound right. You're a DBA but you're not a member of
the SYSADMIN fixed server role? How can you do your job?
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Since we don't want SA running jobs (or being in the Sysadmin group), I set
up a login with win authent, sysadmin to run jobs. No one needs the password
to use; just set this user up as the proxy account (under agent properties,
job system), and if any job owner is not a sysadmin, it defaults to this guy.
HTH, mary
"Alex" wrote:
[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify data.
> The side effect of this is that there are loads of admin tasks we cannot now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Yes, try telling this to the auditors!
We are very frustrated. If we need to add a job we will need to apply for
permission to log in as sa, after going through multilevel of sign off from
the senior management - all for running a SQL Profile, or creating
maintenance plan !!
and then all actions will be be logged as well.
Alex
"Jerry Spivey" wrote:
> Hmmm...that doesn't sound right. You're a DBA but you're not a member of
> the SYSADMIN fixed server role? How can you do your job?
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
|||Curious, if the is a reason to suddenly restore a db in the middle of the day
so production activities can resume, is the same process to log in as SA
required?
ChrisR
"Alex" wrote:
[vbcol=seagreen]
> Yes, try telling this to the auditors!
> We are very frustrated. If we need to add a job we will need to apply for
> permission to log in as sa, after going through multilevel of sign off from
> the senior management - all for running a SQL Profile, or creating
> maintenance plan !!
> and then all actions will be be logged as well.
> Alex
> "Jerry Spivey" wrote:
|||I don't recall anything in SOX that states that a DBA can not have sa
rights. Someone is taking the wording way beyond it's intent. SQL2005 will
have roles specifically for this but in 2000 it is not that easy.
Andrew J. Kelly SQL MVP
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...[vbcol=seagreen]
> Thanks for this. But the problem we have is SOX compliance !. Us dba's
> have
> been stripped off sa/SYSADMIN fixed role permission so we can't modify
> data.
> The side effect of this is that there are loads of admin tasks we cannot
> now
> do.
> Alex
>
> "Jerry Spivey" wrote:
|||Thanks Mary. This could be the escape route we have been looking for!
Alex
"Mary" wrote:
[vbcol=seagreen]
> Since we don't want SA running jobs (or being in the Sysadmin group), I set
> up a login with win authent, sysadmin to run jobs. No one needs the password
> to use; just set this user up as the proxy account (under agent properties,
> job system), and if any job owner is not a sysadmin, it defaults to this guy.
> HTH, mary
> "Alex" wrote:
|||Andrew
We can run sa tasks, but we need authorisation every time we need to. its
like working with one of your hands tied.
Alex
"Andrew J. Kelly" wrote:
> I don't recall anything in SOX that states that a DBA can not have sa
> rights. Someone is taking the wording way beyond it's intent. SQL2005 will
> have roles specifically for this but in 2000 it is not that easy.
> --
> Andrew J. Kelly SQL MVP
>
> "Alex" <Alex@.discussions.microsoft.com> wrote in message
> news:AD536297-1152-4F9E-A36A-88171E6FA033@.microsoft.com...
>
>
Monday, February 20, 2012
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||
Aranda wrote:
The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
Subscribe to:
Posts (Atom)