45 replies to this topic

[antonio9]

I installed the new Windows AIK for Vista SP1 (6001.18000.080118-1840-kb3aik_en.iso)
into the default folder C:\program files\windows AIK
I extracted Winbuilder.rar into my root directory C:\
I started winbuilder.exe as administrator. Then I downloaded the scripts. Set up the source directory for all scripts (c:\program files\windows AIK\). Clicked “Play”

The script “Build>1-Copy Files” fails to copy many of the files from the source directory into “C:\WinBuilder\Temp\VistaPE\BootWimSrc\Windows\System32\”

My many attempts to give permissions to the destination folder yielded the following:
(>Properties>Security dialog)

CREATOR OWNER: Allow only “Special permissions”
SYSTEM: Full Control
Administrators: Full Control
Users: Full Control
(No matter how many combinations I tried going deep into the “advanced” dialogs, I was unable to give full control to the account CREATOR OWNER)

The same results with either UAC on or off. The same results after taken ownership of all subfolders. (I am the only user and log in as tony/administrator)

In order to test the effect of the above permission structure, I was able to copy/paste the first file that was denied destination access, “poqexec.exe”, from Windows AIK into the first three subfolders of the destination directory chain, but unable to do it into the last three subfolders, due to “DESTINATION FOLDER ACCESS DENIED”. Looks like the lack of full permission for the account CREATOR OWNER is causing the copy failures!

I would appreciate it if I could get some comments and suggestions.

[Arvy]

I can certainly understand where you're coming from. Sometimes Vista permissions and inheritance are so frustrating and require so much mouse clicking that I end up rebooting my system to another OS (XP or 2003) and set what I want from there.

Based on what you've said, it seems likely that some of the deeper subfolders have not inherited the parent permissions. If so, the solution is the usual process of taking ownership of them and then telling the parent to replace all subordinate permissions. Another possibility would be overriding denials, but that seems unlikely.

Don't worry too much about the CREATOR OWNER as such. In Vista, ownership and permissions are not as closely linked as they were in prior versions of Windows. Owners, including the Trusted Installer, don't get anything automatically except the ability to make permissions changes. They must specifically set the permissions that they want for themselves as individuals and/or as members of a named group just as for anyone else.

[risolutore]

is there any script tool to "sanitarize" the hard drive in order to give Everybody permission to read and write?

[antonio9]

I can certainly understand where you're coming from. Sometimes Vista permissions and inheritance are so frustrating and require so much mouse clicking that I end up rebooting my system to another OS (XP or 2003) and set what I want from there.

Based on what you've said, it seems likely that some of the deeper subfolders have not inherited the parent permissions. If so, the solution is the usual process of taking ownership of them and then telling the parent to replace all subordinate permissions. Another possibility would be overriding denials, but that seems unlikely.

Don't worry too much about the CREATOR OWNER as such. In Vista, ownership and permissions are not as closely linked as they were in prior versions of Windows. Owners, including the Trusted Installer, don't get anything automatically except the ability to make permissions changes. They must specifically set the permissions that they want for themselves as individuals and/or as members of a named group just as for anyone else.

Thank you, Arvy.

I wonder if you would be able to continue giving me assistance on this. Because this is a royal mess!

After taking ownership of the winbuilder folder and all its subfolders (in my previous attempts I had begun at C:\winbuilder\temp\) I opened this folder security dialog and received this:

Authenticated users: Allow all except Full control and Special permissions
SYSTEM: Full control
Administrators: Full control
Users: Full control

I selected Authenticate Users, clicked the “Edit” button and managed to give full control to this account (1). Then I pressed the “Advanced” button and got this accounts list:

Authenticated users: Full Control <not inherited>
Administrators: special <not inherited>
Users: Full control <not inherited>
Administrators: Full Control <not inherited>
SYSTEM: Full Control inherited from C:\
Users: Read & execute inherited from C:\
Authenticated users: Modify inherited from C:\

Now I really am confused! Assuming that I have not messed it up already, how am I supposed to tell the parent to replace all subordinate permissions? What boxes shall I check and uncheck?

(1) After these two scary messages:”An error occurred while applying security information to C:\winbulder\custom. Access denied” and “Stopping the propagation of permission leads to an inconsisting state, in which some objects have the settings but others don’t”

----------------
Regards
Antonio

[Arvy]

is there any script tool to "sanitarize" the hard drive in order to give Everybody permission to read and write?

If, when you say "the hard drive", you mean the drive on which the Windows Vista OS is installed, DON'T EVEN THINK ABOUT IT! Believe me, you wouldn't be happy with the results. Besides, even if you did that, subsequent operations by Trusted Installer and its pals would just mess it all up again.

[Arvy]

Thank you, Arvy.
I wonder if you would be able to continue giving me assistance on this. Because this is a royal mess!
[...snipped...]
(1) After these two scary messages:”An error occurred while applying security information to C:\winbulder\custom. Access denied” and “Stopping the propagation of permission leads to an inconsisting state, in which some objects have the settings but others don’t”

Step 1: Understand that royal messes and scary messages are often more apparent than real.
Step 2: Don't panic!

It appears more certain than ever that you are faced with a problem of mixed- or non-inheritance of permissions within your primary C:\WinBuilder folder and its subfolders. So long as a situation exists where you (UserX) don't have the ability to alter permissions for every entity (folders and files) subordinate to the primary folder, you will continue to be thwarted by that "Catch-22" situation of (1) an error message telling you so and (2) a scary message about inconsistent propagation when you accept the error message.

How it got that way really doesn't matter right now. In current circumstances, you can't even delete it all and start over. So your first action MUST be to take ownership of the primary C:\WinBuilder folder and EVERYTHING within that folder that you don't already own. Only then will you be able to apply and propagate a consistent set of permissions throughout that entire folder/subfolders/files structure and we can consider specific options for doing so.

Personally, I just gave full control to "Everyone", but mine isn't on my OS drive (neither Vista nor other) and my security environment may differ from yours. So let's discuss that further when you're actually able to implement a decision.

[online]

In Windows Vista the Administrator account is disabled by default and in order to reach Real-Full-Administrator-Privileges you must enable it and disable all other acccounts with Administrator privileges as following:

1. Computer Management > Local Users and Groups > Users > Select "Administrator" (One click) > Right-click (Properties) will show "Account is disabled" > Enable it > OK. (If UAC prompts, answer YES).
Do not set the password!

2. Reboot the machine.

3. Log in Administrator account and disable all other accounts with Administrator privileges in "Computer Management > Local Users and Groups > Users" following above notes for enable it (check "Account is disabled" mark).

4. Be sure that your Administrator account is enabled and reboot the machine.

5. Control Panel > User Accounts > Configure advanced user profile properties > "Account\Unknown" > Delete (Optional: I have done it and now I have only one account on my machine).

6. Control Panel > User Accounts > Set the password for your Administrator account.

7. Then, if you want, you can also rename the Administrator account in "Computer Management > Local Users and Groups > Users".

Now you will reach Real Full Administrator Privileges under Windows Vista.



Btw: the above procedure must be followed with no changes.

[BrianT]

Just Right-Click on WinBuilder and run as admin.

[online]

Just Right-Click on WinBuilder and run as admin.

I started winbuilder.exe as administrator.

[BrianT]

QUOTE (BrianT @ Feb 26 2008, 12:59 AM)
Just Right-Click on WinBuilder and run as admin.


QUOTE (antonio9 @ Feb 25 2008, 05:49 PM)
I started winbuilder.exe as administrator.

Yes but because of UAC you still don't have full admin rights. unless you turn off UAC or right-click and run as.

[allanf]

antonio9,

This may be unimportant, but to clarify:

The script "Build>1-Copy Files" fails to copy many of the files from the source directory into "C:\WinBuilder\Temp\VistaPE\BootWimSrc\Windows\System32\"

'...BootWimSrc\' is the source directory. When VistaPE is building, it is the mounted image from Vista DVD's 'boot.wim', or in case of WAIK only, it is the mounted image from WAIK's 'winpe.wim'. Files are copied from here to '%TargetDir%\' (... Winbuilder\Target\VistaPE\').

In order to test the effect of the above permission structure, I was able to copy/paste the first file that was denied destination access, "poqexec.exe", from Windows AIK...

... from where? ... mounted 'winpe.wim' image, which you have mounted independently of WinBuilder??

...into the first three subfolders of the destination directory chain, but unable to do it into the last three subfolders...

... into where? ... '...Temp\VistaPE\BootWimSrc\'? Is the 'winpe.wim' image mounted in this folder when you try to copy the files? VistaPE unmounts this folder when it finishes. And the files should already exist in this folder when 'winpe.wim' image is mounted to it.

The problem may be copying files from '...BootWimSrc\' to '...'%TargetDir%\'.

Also note that when a Vista DVD is available as the Source, a larger quantity of files are able to be copied from Source to Target. Many files are simply not present in WAIK's 'winpe.wim'. Most importantly, there is no 'install.wim' in WAIK, hence no image mounted to '...Temp\VistaPE\InstallWimSrc\'.

In the 'file copy' Script, select 'Full' to copy the entire 'winpe.wim' image to the Target.

I would appreciate it if I could get some comments and suggestions.

I'm sorry if my questions seem silly, as other members are addressing an entirely different issue. A log file will definitely help.

Regards


EDIT:

After all those Qs, I cannot see any script in VistaPE v.12 beta that attempts to copy your example 'poqexec.exe'. Do VistaPE v.11 and earlier versions work with WAIK 1.1 for Vista SP1? Does WAIK 1.1 even contain 'poqexec.exe'? Hmm....

[online]

Yes but because of UAC you still don't have full admin rights. unless you turn off UAC or right-click and run as.

Yes, but seems to me the same thing as the first... and as we have seen at any case he had already done this too...

The same results with either UAC on or off.

However I cannot know if that trick (about Real Full Administrator Privileges) will work about the thread topic, but surely I know that trick will remove any Windows Vista restriction and annoyance (as thread title), and most of all in presence of only one account (as this case) it will result desiderable... furthermore after that trick UAC will not prompt more.

[booty#1]

is there any script tool to "sanitarize" the hard drive in order to give Everybody permission to read and write?

I have created an addon using setacl.exe that sets Everybody Full control to %TargetDir%.
It is included in VistaPE 12 beta. Therefore this version produces working VistaPEs even if WinBuilder is executed from within a user folders e.g. the desktop.

booty#1

[paraglider]

Vista includes icacls which is an enhanced version of cacls which is also included:


[codebox] ICACLS name /save aclfile [/T] [/C] [/L] [/Q] store the the acls for the all matching names into aclfile for later use with /restore. ICACLS directory [/substitute SidOld SidNew [...]] /restore aclfile [/C] [/L] [/Q] applies the stored acls to files in directory. ICACLS name /setowner user [/T] [/C] [/L] [/Q] changes the owner of all matching names. ICACLS name /findsid Sid [/T] [/C] [/L] [/Q] finds all matching names that contain an ACL explicitly mentioning Sid. ICACLS name /verify [/T] [/C] [/L] [/Q] finds all files whose ACL is not in canonical for or whose lengths are inconsistent with ACE counts. ICACLS name /reset [/T] [/C] [/L] [/Q] replaces acls with default inherited acls for all matching files ICACLS name [/grant[:r] Sid:perm[...]] [/deny Sid:perm [...]] [/remove[:g|:D]] Sid[...]] [/T] [/C] [/L] [/Q] [/setintegritylevel Level:policy[...]] /grant[:r] Sid:perm grants the specified user access rights. With :r, the permissions replace any previouly granted explicit permissions. Without :r, the permissions are added to any previously granted explicit permissions. /deny Sid:perm explicitly denies the specified user access rights. An explicit deny ACE is added for the stated permissions and the same permissions in any explicit grant are removed. /remove[:[g|d]] Sid removes all occurrences of Sid in the acl. With :g, it removes all occurrences of granted rights to that Sid. With :D, it removes all occurrences of denied rights to that Sid. /setintegritylevel [(CI)(OI)]Level explicitly adds an integrity ACE to all matching files. The level is to be specified as one of: L[ow] M[edium] H[igh] Inheritance options for the integrity ACE may precede the level and are applied only to directories. /inheritance:e|d|r e - enables inheritance d - disables inheritance and copy the ACEs r - remove all inherited ACEs Note: Sids may be in either numerical or friendly name form. If a numerical form is given, affix a * to the start of the SID. /T indicates that this operation is performed on all matching files/directories below the directories specified in the name. /C indicates that this operation will continue on all file errors. Error messages will still be displayed. /L indicates that this operation is performed on a symbolic link itself versus its target. /Q indicates that icacls should supress success messages. ICACLS preserves the canonical ordering of ACE entries: Explicit denials Explicit grants Inherited denials Inherited grants perm is a permission mask and can be specified in one of two forms: a sequence of simple rights: F - full access M - modify access RX - read and execute access R - read-only access W - write-only access a comma-separated list in parenthesis of specific rights: D - delete RC - read control WDAC - write DAC WO - write owner S - synchronize AS - access system security MA - maximum allowed GR - generic read GW - generic write GE - generic execute GA - generic all RD - read data/list directory WD - write data/add file AD - append data/add subdirectory REA - read extended attributes WEA - write extended attributes X - execute/traverse DC - delete child RA - read attributes WA - write attributes inheritance rights may precede either form and are applied only to directories: (OI) - object inherit (CI) - container inherit (IO) - inherit only (NP) - don&#39;t propagate inherit Examples: icacls c:\windows\* /save AclFile /T - Will save the ACLs for all files under c:\windows and its subdirectories to AclFile. icacls c:\windows\ /restore AclFile - Will restore the Acls for every file within AclFile that exists in c:\windows and its subdirectories icacls file /grant Administrator:(D,WDAC) - Will grant the user Administrator Delete and Write DAC permissions to file icacls file /grant *S-1-1-0:(D,WDAC) - Will grant the user defined by sid S-1-1-0 Delete and
Write DAC permissions to file
[/codebox]

[antonio9]

In Windows Vista the Administrator account is disabled by default and in order to reach Real-Full-Administrator-Privileges you must enable it and disable all other acccounts with Administrator privileges as following:

1. Computer Management > Local Users and Groups > Users > Select "Administrator" (One click) > Right-click (Properties) will show "Account is disabled" > Enable it > OK. (If UAC prompts, answer YES).
Do not set the password!

2. Reboot the machine.

3. Log in Administrator account and disable all other accounts with Administrator privileges in "Computer Management > Local Users and Groups > Users" following above notes for enable it (check "Account is disabled" mark).

4. Be sure that your Administrator account is enabled and reboot the machine.

5. Control Panel > User Accounts > Configure advanced user profile properties > "Account\Unknown" > Delete (Optional: I have done it and now I have only one account on my machine).

6. Control Panel > User Accounts > Set the password for your Administrator account.

7. Then, if you want, you can also rename the Administrator account in "Computer Management > Local Users and Groups > Users".

Now you will reach Real Full Administrator Privileges under Windows Vista.



Btw: the above procedure must be followed with no changes.

Hi, online

I guess that your instructions for enabling Real –Full-Administrator-Privileges apply to Vista Ultimate, but all I have is Vista Home Premium.

I’ve been trying to follow your instructions, but when I get to “Computer Management” (control panel-system and maintenance-administrative tools-computer management) I find that there is no “Local Users and Groups” section. After much fumbling I simply couldn’t find a way to enable a pure Administrator account. It seems like I’m stuck with my single Tony/Administrator account.

The menu in “Control panel>User Accounts and Family Safety>User Accounts” doesn’t help either.

Please let me know if I’m right in assuming that your instructions only apply to Vista Ultimate. Could there possibly be a workaround for Vista Home Premium?

[antonio9]

antonio9,

This may be unimportant, but to clarify:



'...BootWimSrc\' is the source directory. When VistaPE is building, it is the mounted image from Vista DVD's 'boot.wim', or in case of WAIK only, it is the mounted image from WAIK's 'winpe.wim'. Files are copied from here to '%TargetDir%\' (... Winbuilder\Target\VistaPE\').



... from where? ... mounted 'winpe.wim' image, which you have mounted independently of WinBuilder??



... into where? ... '...Temp\VistaPE\BootWimSrc\'? Is the 'winpe.wim' image mounted in this folder when you try to copy the files? VistaPE unmounts this folder when it finishes. And the files should already exist in this folder when 'winpe.wim' image is mounted to it.

The problem may be copying files from '...BootWimSrc\' to '...'%TargetDir%\'.

Also note that when a Vista DVD is available as the Source, a larger quantity of files are able to be copied from Source to Target. Many files are simply not present in WAIK's 'winpe.wim'. Most importantly, there is no 'install.wim' in WAIK, hence no image mounted to '...Temp\VistaPE\InstallWimSrc\'.

In the 'file copy' Script, select 'Full' to copy the entire 'winpe.wim' image to the Target.



I'm sorry if my questions seem silly, as other members are addressing an entirely different issue. A log file will definitely help.

Regards


EDIT:

After all those Qs, I cannot see any script in VistaPE v.12 beta that attempts to copy your example 'poqexec.exe'. Do VistaPE v.11 and earlier versions work with WAIK 1.1 for Vista SP1? Does WAIK 1.1 even contain 'poqexec.exe'? Hmm....

Allanf,

I am using Windows AIK instead of the Vista DVD because the new AIK supports Vista SP1. Using Daemon tools I mounted the AIK iso file on a virtual drive. Then I run the setup application in the virtual drive and this installed Windows AIK in my “C:\program files\” folder. Winbuilder was installed in “C:\

I have not used the Vista DVD because at this point I understand is not needed if you are using AIK.

Yes, the file that I’m using to test permissions, poqexec.exe, is present in the new AIK.

After running the first 4 scripts in winbuilder the log file shows a failure to copy from a temp subdirectory to a target subdirectory, but I couldn’t find poqexec in the folder %BaseDir%\Temp\VistaPE\BootWimSrc\Windows\System32\ , which was created by winbuider, so I assumed that the failure was originated in the first place when winbuilder was trying to obtain the file from AIK.
As I said in a previous post, I was able to manually copy that file from AIK into the “%BaseDir%\Temp” or “%BaseDir%\Temp\VistaPE” folder, but not into the “%BaseDir%\Temp\VistaPE\BootWimSRC\ folder and subfolders ( in my case %BaseDir% is C:\winbuilder)
I'm including the WinBuilder log file
Regards
Antonio

Attached Files

•  log.zip   56.92KB   361 downloads

[allanf]

As I said in a previous post, I was able to manually copy that file from AIK into the "%BaseDir%\Temp" or "%BaseDir%\Temp\VistaPE" folder, but not into the "%BaseDir%\Temp\VistaPE\BootWimSRC\ folder and subfolders ( in my case %BaseDir% is C:\winbuilder)

'...BootWimSrc\' is a mounted image from WAIK's 'winpe.wim'. Mounted RO, so you will get 'access denied' trying to copy files to it. VistaPE copies files from there to Target.

VistaPE v.12 beta does not try to copy the 'poqexec.exe', from Source to Target. I do not understand where the file is coming from. If it is not in the mounted image of WAIK's 'winpe.wim', then it is not in WAIK. 'winpe.wim' contains a single image, so what you see in '...BootWimSrc\' is all that you get.

BTW, I do not have the new WAIK, so cannot check.

Regards

[allanf]

... I do not understand where the file is coming from....

I see that the file is include in one of my WAIK's Tools folders. But that is not actually the Source of files for VistaPE. The Source is the mounted images from the '.wim' file(s).

[antonio9]

I have created an addon using setacl.exe that sets Everybody Full control to %TargetDir%.
It is included in VistaPE 12 beta. Therefore this version produces working VistaPEs even if WinBuilder is executed from within a user folders e.g. the desktop.

booty#1

booty#1,
I'm intrigued by your addon. Could it be the solution to my problem?
I have downloaded the file setacl.exe, but I'm not sure how to add it to WinBuilder-Project VistaPE v11. Just copying it into the folder "C:\winbuilder\projects\vistaPE\addons\" doesn't seem to work.
Also I'd like to download the application WinBuilder with VistaPE v12, but when I click on VistaPE Core v12 (beta) in the page "www.vistape.net/beta" all I get is a script text but no means to download the file.
I would appreciate your help.
Regards
Antonio

[antonio9]

I see that the file is include in one of my WAIK's Tools folders. But that is not actually the Source of files for VistaPE. The Source is the mounted images from the '.wim' file(s).

allanf,
You may be right since I'm not clear about the whole process. So my little exercise with the file poqexec.exe was useless! But the fact remains that winbuilder-VistaPE v11 obtains many files from WAIK, but fails to obtain many other.
I'm now downloading the scripts for VistaPE Core v12 .Hope this will solve my problems.
Regards,
Antonio

[online]

Please let me know if I'm right in assuming that your instructions only apply to Vista Ultimate. Could there possibly be a workaround for Vista Home Premium?

Hi, antonio9.

On the premise that the file "poqexec.exe" is regularly required from "Standard-1-files.script" under VistaPE 011 and that it was "commented" in "04-additional.script" under next 012 Beta versions (then, all seems right about your first environment base) I have to confirm that unfortunely the described trick does not work in Vista Home Premium due to missed "Local Users and Groups" MMC snap-in under that version of Vista...

However I found a workaround that I've not tried, but that would must do the same thing.

Following these instructions you can enable Administrator account (and then disable your current account) by command-line:

To enable the build-in Administrator account, follow these steps:
1. Click Start, and then type cmd in the Start Search box.
2. In the search results list, right-click Command Prompt, and then click Run as Administrator.
3. When you are prompted by User Account Control, click Continue.
4. At the command prompt, type net user administrator /active:yes, and then press ENTER.
5. Type net user administrator <Password>, and then press ENTER.
Note: Please replace the <Password> tag with your passwords which you want to set to administrator account.
6. Type exit, and then press ENTER.
7. Log off the current user account

7. Reboot your machine and then log-in the Administrator account just created.

In order to disable your previous account:

net user username /active:no

where "username" is your user account name.

Then, reboot your machine... etc. etc.

I repeat that I do not tried that procedure and that I assume "command-line" method will have the same effect of previous one...

Furthermore, please note that you must set the password of your Administrator account only in "Control Panel > User Accounts" and only after the complete (integrated with previous ones, replacing related ones) procedure and then after at least a couple of reboot (you will set your Administrator password when you will be sure that all works fine about accounts enabling/disabling).
Before to proceed you have to do a complete backup of your system.


Btw: we still cannot know if the above way will solve your issue, but if you want definitively remove your Windows Vista restrictions actually it seems the only way...

[antonio9]

Hi, antonio9.

On the premise that the file "poqexec.exe" is regularly required from "Standard-1-files.script" under VistaPE 011 and that it was "commented" in "04-additional.script" under next 012 Beta versions (then, all seems right about your first environment base) I have to confirm that unfortunely the described trick does not work in Vista Home Premium due to missed "Local Users and Groups" MMC snap-in under that version of Vista...

However I found a workaround that I've not tried, but that would must do the same thing.

Following these instructions you can enable Administrator account (and then disable your current account) by command-line:

To enable the build-in Administrator account, follow these steps:
1. Click Start, and then type cmd in the Start Search box.
2. In the search results list, right-click Command Prompt, and then click Run as Administrator.
3. When you are prompted by User Account Control, click Continue.
4. At the command prompt, type net user administrator /active:yes, and then press ENTER.
5. Type net user administrator <Password>, and then press ENTER.
Note: Please replace the <Password> tag with your passwords which you want to set to administrator account.
6. Type exit, and then press ENTER.
7. Log off the current user account

7. Reboot your machine and then log-in the Administrator account just created.

In order to disable your previous account:

net user username /active:no

where "username" is your user account name.

Then, reboot your machine... etc. etc.

I repeat that I do not tried that procedure and that I assume "command-line" method will have the same effect of previous one...

Furthermore, please note that you must set the password of your Administrator account only in "Control Panel > User Accounts" and only after the complete (integrated with previous ones, replacing related ones) procedure and then after at least a couple of reboot (you will set your Administrator password when you will be sure that all works fine about accounts enabling/disabling).
Before to proceed you have to do a complete backup of your system.


Btw: we still cannot know if the above way will solve your issue, but if you want definitively remove your Windows Vista restrictions actually it seems the only way...

Hi online,
I remember trying that workaround once. At the first reboot I received the dialog window asking for a password. I have never used a password to boot my vista OS and normally my boot sequence skips this dialog. This was a dead-end because I was unable to leave in blank the box for the password. I recovered inserting my Vista DVD, and going to the Repair your Computer menu. Then I selected a previous system restore point.
The workaround may work, but its application is tricky. Maybe the lines you crossed out are needed!
Regards

[antonio9]

I have created an addon using setacl.exe that sets Everybody Full control to %TargetDir%.
It is included in VistaPE 12 beta. Therefore this version produces working VistaPEs even if WinBuilder is executed from within a user folders e.g. the desktop.

booty#1

Finally, I downloaded the scripts for the project VistaPE 12 beta in Winbuilder, and clicked "Play". Unfortunately, winbuilder stopped at "Error extracting system files! Please send full log file to vistape@vistape.net". I did so.
If you like, you can also review the log file in the attachement.
Regards.

Attached Files

•  log.7z   22.42KB   401 downloads

[antonio9]

Step 1: Understand that royal messes and scary messages are often more apparent than real.
Step 2: Don't panic!

It appears more certain than ever that you are faced with a problem of mixed- or non-inheritance of permissions within your primary C:\WinBuilder folder and its subfolders. So long as a situation exists where you (UserX) don't have the ability to alter permissions for every entity (folders and files) subordinate to the primary folder, you will continue to be thwarted by that "Catch-22" situation of (1) an error message telling you so and (2) a scary message about inconsistent propagation when you accept the error message.

How it got that way really doesn't matter right now. In current circumstances, you can't even delete it all and start over. So your first action MUST be to take ownership of the primary C:\WinBuilder folder and EVERYTHING within that folder that you don't already own. Only then will you be able to apply and propagate a consistent set of permissions throughout that entire folder/subfolders/files structure and we can consider specific options for doing so.

Personally, I just gave full control to "Everyone", but mine isn't on my OS drive (neither Vista nor other) and my security environment may differ from yours. So let's discuss that further when you're actually able to implement a decision.

I have already taken ownership of the primary C:\WinBuilder folder (I use a little own.reg file that adds
a very convenient "Take Ownership" option to the menu you get when you right-click a file or folder).
I need help in the specific steps required to apply and propagate a consistent set of permissions throughout the entire folder/subfolders/files structure (if it is possible). You can review my travails while I was trying to give full control to "Everyone", in my original post and in my reply to arby. Actually, I am in a "desperation" phase where I believe that what I'm trying to do is just not possible on Vista Home Premium! Apparently, there is workaround that may work on Vista Ultimate.
Regards,
Antonio

[allanf]

... Unfortunately, winbuilder stopped at "Error extracting system files! Please send full log file to vistape@vistape.net". I did so.
...

That sounds like a real Vista permissions issue. See here and referenced thread therein. Unfortunately no solution as yet, and I cannot duplicate the error because I don't have Vista.