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 ACLs. ---
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.
>>
>>