Re: SMS Backup Task
- From: "Steve Thompson" <stevethompson@xxxxxxxxxxxxx>
- Date: Fri, 11 Nov 2005 09:49:03 -0500
You are right on all of those points -- I was wondering if that solves the
issue. Which in turn means Microsoft needs to fix that behavior...
Steve
"Tony Gardner" <tgardner100@xxxxxxxxxxx> wrote in message
news:e0Zsg1o5FHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
>
> No, it is not a local administrator. By making the SQL Service Account a
> domain user, it is more supposed to be more secure. It appears from the
> testing here that SMS does not support SQL running as a domain user
account
> that is not an administrator. The fact that a directory can be deleted
and
> re-created without inheritence is also bad karma.
>
> In the MS SMS Security Guide it does recommend making SQL run as domain
> user. Bit of a inconsistency here!
>
>
> "Steve Thompson" <stevethompson@xxxxxxxxxxxxx> wrote in message
> news:%23egOHef5FHA.3544@xxxxxxxxxxxxxxxxxxxxxxx
> > Is your SQL Server service account a local administrator on the server?
> >
> > "Tony Gardner" <tgardner100@xxxxxxxxxxx> wrote in message
> > news:uCJhHPV5FHA.1148@xxxxxxxxxxxxxxxxxxxxxxx
> >> Yes, but note when it runs the task it deletes the subdirectory and
> >> recreates it with administrators with full permissions (no
inheritence).
> > So
> >> it doesn't matter what permissions I add, it still doesn't add them to
> >> the
> >> newly created folders.
> >>
> >>
> >>
> >>
> >> "Steve Thompson" <stevethompson@xxxxxxxxxxxxx> wrote in message
> >> news:uvtUekU5FHA.2040@xxxxxxxxxxxxxxxxxxxxxxx
> >> > "Tony Gardner" <tgardner100@xxxxxxxxxxx> wrote in message
> >> > news:Ot5v40P5FHA.3496@xxxxxxxxxxxxxxxxxxxxxxx
> >> >
> >> >> I have configured the SMS backup task to backup SMS. The SQL server
> >> >> is
> >> >> running as a domain user. W2K3, SMS2003SP1, SQL2000SP4
> >> >>
> >> >> When the job runs, SQL reports that it cannot write to the SMS
backup
> >> >> location (D:\backup). 4 errors appear in the Application log saying
> >> >> it
> >> >> cannot write files.
> >> >>
> >> >> What appears to happen is that as the task runs, it deletes the
> >> >> D:\backup\<sitebackupname> directory and recreates it. It recreates
> > the
> >> >> directory with administrators full control (no inheritence), the SQL
> >> > backup
> >> >> job cannot write to this directory.
> >> >>
> >> >> Now I could give the account administrator rights, or change to a
> >> >> local
> >> >> system but that defeats the purpose of changing to a local user.
> >> >>
> >> >> I have modified the sitebackup file to dump the files to a different
> >> >> directory then copy the files into their proper location. Its a
> >> >> temporary
> >> >> workaround but I am after something more permanent.
> >> >>
> >> >> I was wondering if this issue is an anomoly, a "feature", documented
> >> >> fault
> >> > ?
> >> >> and whether there is a solution for this?
> >> >
> >> > Have you tried granting both SYSTEM & the account that SQL server
runs
> >> > under
> >> > full control to the "D:\backup" folder level?
> >> >
> >> > Steve
> >> >
> >> >
> >>
> >>
> >
> >
>
>
.
- References:
- SMS Backup Task
- From: Tony Gardner
- Re: SMS Backup Task
- From: Steve Thompson
- Re: SMS Backup Task
- From: Tony Gardner
- SMS Backup Task
- Prev by Date: Re: Removing a DP
- Next by Date: Re: CryptGenKey failed: 0x80090020
- Previous by thread: Re: SMS Backup Task
- Next by thread: Re: Display Active Directory LOCATION
- Index(es):
Relevant Pages
|