Steve--Thank you; copy/paste did the trick! I was making a spacing syntax
error--sorry to trouble you. Happy New Year--Al

"Steven L Umbach" wrote:

> It should work and I just tried it on an XP Pro computer of mine to make
> sure. I just copied and pasted the command from the KB article and added
> /areas filestore to the end of the command. Below is the result. It does not
> matter if it is a domain computer or not. --- Steve
>
> D:\Documents and Settings\Steve>secedit /configure /cfg
> %windir%\repair\secsetup
> ..inf /db secsetup.sdb /verbose /areas filestore
>
> Task is completed. Some files in the configuration are not found on this
> system
> so security cannot be set/queried. It's ok to ignore.
> See log %windir%\security\logs\scesrv.log for detail info.
>
> D:\Documents and Settings\Steve>
>
>
> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> news:711E1ACE-61FE-463F-8CCB-F9F6734CE6D6@microsoft.com...
> > Steve--I'm having trouble getting secedit/configure to function per
> > kbid3132220; it keeps returning to command prompt and opening help as if I
> > had entered %windir%\help\secedit.chm. I tried various syntax adjustments
> > such as space/no-space between parameter labels and filenames. I found
> > that
> > the database file, secsetup.sdb did not exist in the windows root, the
> > windows\repair, or the windows\security\database directories, so I
> > launched
> > mmc, snapped-in Security Configuration and Analysis tool and asked it to
> > analyze using secsetup.sdb with secsetup.inf template. That seemed to
> > work
> > and generated the secsetup.sdb which I then tried to use with the
> > secedit/configure command, but still same result.
> > There must be something basic I'm failing to do. Any idea? Or, is it
> > possible that secedit works only with group policy in domain? Our two
> > Win-XP-Pro systems operate standalone or as peers in workgroup only w/o
> > server. Should I use different tool in my case? Regards--Al
> >
> > "Steven L Umbach" wrote:
> >
> >> Sounds good. If you get time let me know if it does what you need or
> >> t. --- Steve
> >>
> >>
> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> news99023D4-9A1F-4F30-9A87-5E26CB0B402D@microsoft.com...
> >> > Steve--Thank you; I plan to follow your suggestion and use secedit with
> >> > the
> >> > areas filestore switch. Wishing you the blessing of Christmas--Al
> >> >
> >> > "Steven L Umbach" wrote:
> >> >
> >> >> I believe the KB article will use a security template that is in the
> >> >> \windows\repair folder that is used during computer original
> >> >> configuration
> >> >> and probably is closer to what default setting would be than setup
> >> >> security.inf. You could compare the two security templates with the
> >> >> Security
> >> >> Configuration and Analysis mmc snapin or viewing them with the
> >> >> Security
> >> >> template mmc snapin. Either way you may want to use the /areas
> >> >> filestore
> >> >> switch to change just file permissions. --- Steve
> >> >>
> >> >>
> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> >> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
> >> >> > Steve--Thank you; secedit is sounding better, but under the
> >> >> > circumstances
> >> >> > which is the better solution, "secedit" or "setup security.inf" the
> >> >> > predefined security template? Will either do the job? If so, what
> >> >> > are
> >> >> > pros
> >> >> > and cons of each?--Al
> >> >> >
> >> >> > "Steven L Umbach" wrote:
> >> >> >
> >> >> >> You can go ahead an use secedit as described in the KB but you may
> >> >> >> find
> >> >> >> that
> >> >> >> user/group permissions that you had defined to be other than
> >> >> >> default
> >> >> >> probably will be changed back to default which is a fairly secure
> >> >> >> setup
> >> >> >> but
> >> >> >> may deny access to non default groups that you have added. An
> >> >> >> administer
> >> >> >> will be able to logon to run/configure applications and manage
> >> >> >> Ls. ---
> >> >> >> Steve
> >> >> >>
> >> >> >>
> >> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> >> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
> >> >> >> > Ian--Thank you for sharing your experience with SECEDIT on
> >> >> >> > FAT-to-NTFS,
> >> >> >> > but I
> >> >> >> > think our new machines came formatted NTFS--Simple Permissions
> >> >> >> > (that's
> >> >> >> > not
> >> >> >> > FAT is it?), and I changed settings to NTFS--Special Permissions.
> >> >> >> >
> >> >> >> > I agree with your advice to change only Sharing Permissions and
> >> >> >> > not
> >> >> >> > NTFS
> >> >> >> > Security Permissions. But I think the problem is not that I
> >> >> >> > changed
> >> >> >> > security
> >> >> >> > permissions just for user Documents and Settings but for the
> >> >> >> > entire
> >> >> >> > "C"-drive, and I mistakenly pushed those changes down via
> >> >> >> > inheritance
> >> >> >> > to
> >> >> >> > folders/files in all sub-directories, including Program Files and
> >> >> >> > Windows!
> >> >> >> > (My advice to others: never tamper while ignorant and tired.)
> >> >> >> >
> >> >> >> > So before I create a bigger problem, I need to know if there is
> >> >> >> > anything I
> >> >> >> > should know about using SECEDIT to reset defaults? For example,
> >> >> >> > will
> >> >> >> > I
> >> >> >> > need
> >> >> >> > to reload apps?
> >> >> >> >
> >> >> >> > --
> >> >> >> > aws
> >> >> >> >
> >> >> >> >
> >> >> >> > "Ian" wrote:
> >> >> >> >
> >> >> >> >> > KB 313222
> >> >> >> >>
> >> >> >> >> Tried this on a test machine, and it did what it was supposed
> >> >> >> >> to.
> >> >> >> >> HST
> >> >> >> >> this
> >> >> >> >> machine had no NTFS permissions (was setup on FAT and converted)
> >> >> >> >> not
> >> >> >> >> sure if
> >> >> >> >> the same would apply with unusual permissions set.
> >> >> >> >>
> >> >> >> >> As for the difference -- not sure.
> >> >> >> >>
> >> >> >> >> For controlling access to shares I'd always advocate using share
> >> >> >> >> permissions. Share permissions are more limited in scope, but
> >> >> >> >> behave
> >> >> >> >> more
> >> >> >> >> predictably. The problem with folder-permissions is that they
> >> >> >> >> 'stick
> >> >> >> >> to'
> >> >> >> >> files when the files are transferred elsewhere within the same
> >> >> >> >> tree,
> >> >> >> >> and
> >> >> >> >> this
> >> >> >> >> causes no end of confusion.
> >> >> >> >>
> >> >> >> >> If you _are_ going to set folder-permissions, then the classic
> >> >> >> >> pitfall
> >> >> >> >> is
> >> >> >> >> to
> >> >> >> >> forget to include the Administrator(s) in the ACL. Make this
> >> >> >> >> mistake
> >> >> >> >> in a
> >> >> >> >> good few places, and you'll find you've made yourself a load of
> >> >> >> >> grief.
> >> >> >> >> The
> >> >> >> >> other thing to be careful of is not to create a situation in
> >> >> >> >> which
> >> >> >> >> the
> >> >> >> >> contents can't be read under whatever account the system-backup
> >> >> >> >> runs.
> >> >> >> >> This is
> >> >> >> >> less likely with tape but very possible with disk-to-disk (NAS)
> >> >> >> >> backup.
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Cool. I am a terrible typist. I always cut and paste where I can. Great that
you got it to work. --- Steve


"Al Small" <AlSmall@discussions.microsoft.com> wrote in message
news:59D615F6-58A2-4B89-8E97-76B51A91E158@microsoft.com...
> Steve--Thank you; copy/paste did the trick! I was making a spacing syntax
> error--sorry to trouble you. Happy New Year--Al
>
> "Steven L Umbach" wrote:
>
>> It should work and I just tried it on an XP Pro computer of mine to make
>> sure. I just copied and pasted the command from the KB article and added
>> /areas filestore to the end of the command. Below is the result. It does
>> not
>> matter if it is a domain computer or not. --- Steve
>>
>> D:\Documents and Settings\Steve>secedit /configure /cfg
>> %windir%\repair\secsetup
>> ..inf /db secsetup.sdb /verbose /areas filestore
>>
>> Task is completed. Some files in the configuration are not found on this
>> system
>> so security cannot be set/queried. It's ok to ignore.
>> See log %windir%\security\logs\scesrv.log for detail info.
>>
>> D:\Documents and Settings\Steve>
>>
>>
>> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> news:711E1ACE-61FE-463F-8CCB-F9F6734CE6D6@microsoft.com...
>> > Steve--I'm having trouble getting secedit/configure to function per
>> > kbid3132220; it keeps returning to command prompt and opening help as
>> > if I
>> > had entered %windir%\help\secedit.chm. I tried various syntax
>> > adjustments
>> > such as space/no-space between parameter labels and filenames. I found
>> > that
>> > the database file, secsetup.sdb did not exist in the windows root, the
>> > windows\repair, or the windows\security\database directories, so I
>> > launched
>> > mmc, snapped-in Security Configuration and Analysis tool and asked it
>> > to
>> > analyze using secsetup.sdb with secsetup.inf template. That seemed to
>> > work
>> > and generated the secsetup.sdb which I then tried to use with the
>> > secedit/configure command, but still same result.
>> > There must be something basic I'm failing to do. Any idea? Or, is it
>> > possible that secedit works only with group policy in domain? Our two
>> > Win-XP-Pro systems operate standalone or as peers in workgroup only w/o
>> > server. Should I use different tool in my case? Regards--Al
>> >
>> > "Steven L Umbach" wrote:
>> >
>> >> Sounds good. If you get time let me know if it does what you need or
>> >> t. --- Steve
>> >>
>> >>
>> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> news99023D4-9A1F-4F30-9A87-5E26CB0B402D@microsoft.com...
>> >> > Steve--Thank you; I plan to follow your suggestion and use secedit
>> >> > with
>> >> > the
>> >> > areas filestore switch. Wishing you the blessing of Christmas--Al
>> >> >
>> >> > "Steven L Umbach" wrote:
>> >> >
>> >> >> I believe the KB article will use a security template that is in
>> >> >> the
>> >> >> \windows\repair folder that is used during computer original
>> >> >> configuration
>> >> >> and probably is closer to what default setting would be than setup
>> >> >> security.inf. You could compare the two security templates with the
>> >> >> Security
>> >> >> Configuration and Analysis mmc snapin or viewing them with the
>> >> >> Security
>> >> >> template mmc snapin. Either way you may want to use the /areas
>> >> >> filestore
>> >> >> switch to change just file permissions. --- Steve
>> >> >>
>> >> >>
>> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> >> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
>> >> >> > Steve--Thank you; secedit is sounding better, but under the
>> >> >> > circumstances
>> >> >> > which is the better solution, "secedit" or "setup security.inf"
>> >> >> > the
>> >> >> > predefined security template? Will either do the job? If so,
>> >> >> > what
>> >> >> > are
>> >> >> > pros
>> >> >> > and cons of each?--Al
>> >> >> >
>> >> >> > "Steven L Umbach" wrote:
>> >> >> >
>> >> >> >> You can go ahead an use secedit as described in the KB but you
>> >> >> >> may
>> >> >> >> find
>> >> >> >> that
>> >> >> >> user/group permissions that you had defined to be other than
>> >> >> >> default
>> >> >> >> probably will be changed back to default which is a fairly
>> >> >> >> secure
>> >> >> >> setup
>> >> >> >> but
>> >> >> >> may deny access to non default groups that you have added. An
>> >> >> >> administer
>> >> >> >> will be able to logon to run/configure applications and manage
>> >> >> >> Ls. ---
>> >> >> >> Steve
>> >> >> >>
>> >> >> >>
>> >> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> >> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
>> >> >> >> > Ian--Thank you for sharing your experience with SECEDIT on
>> >> >> >> > FAT-to-NTFS,
>> >> >> >> > but I
>> >> >> >> > think our new machines came formatted NTFS--Simple Permissions
>> >> >> >> > (that's
>> >> >> >> > not
>> >> >> >> > FAT is it?), and I changed settings to NTFS--Special
>> >> >> >> > Permissions.
>> >> >> >> >
>> >> >> >> > I agree with your advice to change only Sharing Permissions
>> >> >> >> > and
>> >> >> >> > not
>> >> >> >> > NTFS
>> >> >> >> > Security Permissions. But I think the problem is not that I
>> >> >> >> > changed
>> >> >> >> > security
>> >> >> >> > permissions just for user Documents and Settings but for the
>> >> >> >> > entire
>> >> >> >> > "C"-drive, and I mistakenly pushed those changes down via
>> >> >> >> > inheritance
>> >> >> >> > to
>> >> >> >> > folders/files in all sub-directories, including Program Files
>> >> >> >> > and
>> >> >> >> > Windows!
>> >> >> >> > (My advice to others: never tamper while ignorant and tired.)
>> >> >> >> >
>> >> >> >> > So before I create a bigger problem, I need to know if there
>> >> >> >> > is
>> >> >> >> > anything I
>> >> >> >> > should know about using SECEDIT to reset defaults? For
>> >> >> >> > example,
>> >> >> >> > will
>> >> >> >> > I
>> >> >> >> > need
>> >> >> >> > to reload apps?
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > aws
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > "Ian" wrote:
>> >> >> >> >
>> >> >> >> >> > KB 313222
>> >> >> >> >>
>> >> >> >> >> Tried this on a test machine, and it did what it was supposed
>> >> >> >> >> to.
>> >> >> >> >> HST
>> >> >> >> >> this
>> >> >> >> >> machine had no NTFS permissions (was setup on FAT and
>> >> >> >> >> converted)
>> >> >> >> >> not
>> >> >> >> >> sure if
>> >> >> >> >> the same would apply with unusual permissions set.
>> >> >> >> >>
>> >> >> >> >> As for the difference -- not sure.
>> >> >> >> >>
>> >> >> >> >> For controlling access to shares I'd always advocate using
>> >> >> >> >> share
>> >> >> >> >> permissions. Share permissions are more limited in scope, but
>> >> >> >> >> behave
>> >> >> >> >> more
>> >> >> >> >> predictably. The problem with folder-permissions is that they
>> >> >> >> >> 'stick
>> >> >> >> >> to'
>> >> >> >> >> files when the files are transferred elsewhere within the
>> >> >> >> >> same
>> >> >> >> >> tree,
>> >> >> >> >> and
>> >> >> >> >> this
>> >> >> >> >> causes no end of confusion.
>> >> >> >> >>
>> >> >> >> >> If you _are_ going to set folder-permissions, then the
>> >> >> >> >> classic
>> >> >> >> >> pitfall
>> >> >> >> >> is
>> >> >> >> >> to
>> >> >> >> >> forget to include the Administrator(s) in the ACL. Make this
>> >> >> >> >> mistake
>> >> >> >> >> in a
>> >> >> >> >> good few places, and you'll find you've made yourself a load
>> >> >> >> >> of
>> >> >> >> >> grief.
>> >> >> >> >> The
>> >> >> >> >> other thing to be careful of is not to create a situation in
>> >> >> >> >> which
>> >> >> >> >> the
>> >> >> >> >> contents can't be read under whatever account the
>> >> >> >> >> system-backup
>> >> >> >> >> runs.
>> >> >> >> >> This is
>> >> >> >> >> less likely with tape but very possible with disk-to-disk
>> >> >> >> >> (NAS)
>> >> >> >> >> backup.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>