Software Deployment

SetACL, SubInACL, XCACLS...? My own preference - in a packaging environment - is for the first.

For other purposes, I converted a MS-authored VBScript class file (I also converted it into a Windows Scripting Component) and used that as an object within other VBScripts which set permissions. I *think* it was originally called DACLS.VBS but don't quote me. IIRC, it requires the presence and registration of ADsSecurity.DLL but I think most XP systems include that. Again, don't quote me on either of those assertions!

Hi VBScab,

Thanks a lot for your inputs. I would appreciate if you give some more inputs, which will be very userful.

Different permissions are to be given to so many folders and files (program files and folders, system files and folders, and others) for different types of users, (like power user, domain user, administrator and others). We can use SetACL, SubInACL, XCACLS any one of them, but giving permissions to all these files and folders will become a lengthy script. Other than GPO is there any other way with which we can set permissions to different types of users for all files and folders in the system and also for some important registries.

Also our .sdb file does set minimum and maximum passwords, password complexity, other lockout related settings, guest account, admin name etc. I have searched some of them in registry, but I am not able to find password complexity and others, so can you suggest how shall I implement this in the script.

Thanks in advance.

Regards
Ramesh

Er, why isn't this stuff in the build? Retrospectively permissioning workstations is, as you've found, painful. IMV, it would be quicker to create a correctly-permissioned build and re-image your workstations.

Password complexity and history and such things should be defined by Group Policy.

Can I politely suggest that you employ the services of a Build Engineer?

Hi VBScab,

Yes, you are right :)

But as of now we are not deploying a standard PC through images but through a script that installs the required components on workstations. The same script first executes .sdb file for permissioning workstations then installs various components.

For Password complexity and history do we not have any other option other than grou policy?

Thanks in advace
Regards
Ramesh

For Password complexity and history do we not have any other option other than grou policy?Since policies ultimately get written to the registry anyway, you *could* script it but and GP makes it an order of magnitude easier to administer and apply. GP would be the optimal choice.