Re: TakeOwnership Doesn't (XP)
- From: Gerry Hickman <gerry666uk2@xxxxxxxxxxxxxxxx>
- Date: Mon, 02 Feb 2009 17:02:34 +0000
Hi,
I am confused by your reference to "Correct privileges if working on a local machine." I am running the script on my XP desktop , but the files in questions are on the SAN - shared via DFS.
Even if are logged in as a domain admin, you may still need to enable privileges when working on a local machine with files referenced by a local path. It's best to test locally before testing on the SAN.
In general, UNC paths don't work very well with WMI, so you would instead connect to the file server first - who sees the SAN as local storage, but with DFS I don't know if there's a way to reference the files with a local path.
I am logged on as a Domain Admin, so I would _think_ any needed privileges would be in place by default. I guess I can log in to the cluster serving the SAN drives and check...
Also, it appears that ICACLS is not valid for XP, so I cannot use it from my desktop. XCACLS seems a bit flakey, so I am thinking I might load ICACLS onto one of our 2003 servers and run the script from there.
Thanks much for all your help,
MM
"Gerry Hickman" wrote:
Hi,
I have now tested this more carefully on Vista and have been able to take ownership of all objects in a tree with just one call. See code snippet below. Note that you must have correct privs enabled if working on a local machine, something like this:
// Add privs for local machines
oSvc.Security_.Privileges.AddAsString("SeRestorePrivilege", true);
oSvc.Security_.Privileges.AddAsString("SeTakeOwnershipPrivilege", true);
oSvc.Security_.Privileges.AddAsString("SeSecurityPrivilege", true);
function takeOwnerShip() {
// Take Ownership
_trace("Processing Owner");
var oMethod = oDir.Methods_.Item("TakeOwnerShipEx");
var oInParam = oMethod.InParameters.SpawnInstance_();
oInParam.Recursive = true;
var oOutParam = oDir.ExecMethod_(oMethod.Name, oInParam);
_trace("RetVal is " + oOutParam.ReturnValue);
}
--
Gerry Hickman
London (UK)
"MarkMcB" <MarkMcB@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:17B5726C-D08E-4A6C-ACEB-87CF3C7D8092@xxxxxxxxxxxxxxxxYour understanding is correct.
It appears to cycle thru sub-files and folders until it hits the first one
that resists change. Then it just gives up. But it usually gets farther
each successive time I run it.
I have noticed that there is a STOPfile and STARTfile parameter and I am now
trying to make use of those, but that still seems convoluted. It just seems
like there should be a cleaner way to do this.
Thanks again,
MM
"Gerry Hickman" wrote:
Hi,
I'm not aware of anything different on Vista regarding this. I think
you're saying you can take ownership of the starting folder and it
always works, but it doesn't set the ownership of all child objects in
the tree in one go. Is that correct?
I need to set up a test for this.
MarkMcB wrote:Hello,
Yes, I agree the TakeOwnership method should work the same. However,
although I have no firsthand knowledge, I heard Vista implemented some
additional file security that complicates the problem on that OS.
The baffling part is that is just does not work as documented for me. I do
not understand why it only works half way and I have to keep calling it. It
is supposed to be recursive, and I see nothing in the MS documentation to
qualify or clarify that...
Thanks,
MM
"Gerry Hickman" wrote:
Hi,
I didn't get as far as testing with recursive folders, but I'm fairly sure
the call to Win32_Directory.TakeOwnership() works the same on XP, Win2003
and Vista.
--
Gerry Hickman
London (UK)
"MarkMcB" <MarkMcB@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:110FB9CD-A5BB-45C9-A8F5-AC1BD0FE07CB@xxxxxxxxxxxxxxxx
Hello Gerry and thanks for the quick response.
I had already seen the thread you mention, but it seems to apply only to
Vista. (I'm running XP and Server 2k & 2003.)
After going back to using a mapped drive rather than the DFS URL, I have
determined that the TakeOwnership script as outlined only works on the top
level folder initially. However, it appears that successive iterations of
the TakeOwnership command and CACLS calls enable it to perform it's
recursive
function 1 layer at a time.
Very strange, but I have verified it. The script I use is what I listed
previously, but includes a second bit that call CACLS to open up the
permissions on the same folder structures. After the first run, only the
base folder itself is correct, but if I execute the same script again the
next level of files and folders is done. I am about to just put both of
these functions inside a DO UNTIL loop, but that seems awfully awkward and
contrary to documantation.
I would definitely like a cleaner solution, but I'll move forward with
this
unless I hear of a better idea.
Thanks Again!
MM
"Gerry Hickman" wrote:
Hi,
See the thread "NTFS operation fails in WMI, works in GUI". Please also
test
first using a local path, not a DFS path.
--
Gerry Hickman
London (UK)
--
Gerry Hickman (London UK)
--
Gerry Hickman (London UK)
.
- Follow-Ups:
- Re: TakeOwnership Doesn't (XP)
- From: MarkMcB
- Re: TakeOwnership Doesn't (XP)
- From: MarkMcB
- Re: TakeOwnership Doesn't (XP)
- From: MarkMcB
- Re: TakeOwnership Doesn't (XP)
- References:
- Re: TakeOwnership Doesn't (XP)
- From: MarkMcB
- Re: TakeOwnership Doesn't (XP)
- Prev by Date: Re: TakeOwnership Doesn't (XP)
- Next by Date: Re: Securing win32_process.create ?
- Previous by thread: Re: TakeOwnership Doesn't (XP)
- Next by thread: Re: TakeOwnership Doesn't (XP)
- Index(es):
Relevant Pages
|
Loading