| Author |
Topic  |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/11/2011 : 1:09:06 PM
|
I have a simple script which takes the name of a user, the name of a computer, and deletes the local profile off of it. This is being launched by me, a Domain Admin, the powershell shell is run "As Administrator".
I can delete this folder interactively at the GUI, and I can also do it with a batch file. However, Powershell reports access denied.
param($UserID,$Computer)
$strLocalProfile = "\\$Computer\c$\Users\$UserID"
Write-Host "Deleting profile directory [$strLocalProfile]"
Remove-Item -Path $strLocalProfile -Recurse -Force
Executing .\ClearUserProfile.ps1 KFrog VMWSDA04
I get this back...
PS U:\scripts\W7Migrate> .\ClearProfile.ps1 KFrog VMWSDA04
Deleting profile directory [\\VMWSDA04\c$\Users\KFrog]
Remove-Item : Access to the path '\\VMWSDA04\c$\Users\KFrog\AppData\Local\Application Data' is denied.
At U:\scripts\W7Migrate\ClearProfile.ps1:5 char:12
+ Remove-Item <<<< -Path $strLocalProfile -Recurse -Force
+ CategoryInfo : PermissionDenied: (\\VMWSDA04\c$\Users\KFrog:String) [Remove-Item], UnauthorizedAccessEx
ception
+ FullyQualifiedErrorId : RemoveItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.RemoveItemCommand
Given that it is tripping on "Application Data" (which is a junction in Windows 7) it seems to indicate that Remove-Item can't delete junctions.
From good old batch, everything works fine.
@echo off
set LocalProfile="\\%2\c$\Users\%1"
echo Deleting profile directory [%LocalProfile%]
rd /s /q %LocalProfile%
I'm thinking my understanding of how the Remove-Item CmdLet works is not correct. I'm looking to just simply blow away a folder tree.
Edit - I can verify that the profile is NOT in use. User is logged off, in fact I'm trying this on several old profiles that have not see n use in months. Like I said, works fine from batch file.
|
Edited by - sixdoubleo on 08/11/2011 1:29:47 PM |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/11/2011 : 1:20:14 PM
|
get-help remove-item shows this...
-Recurse [<SwitchParameter>]
Deletes the items in the specified locations and in all child items of the locations.
The Recurse parameter in this cmdlet does not work properly.
Huh?
Also, none of the examples for using Remove-Item show how to remove a directory...something I find interesting as...oh, I don't know...seems like it'd be common. |
Edited by - sixdoubleo on 08/11/2011 1:28:22 PM |
 |
|
|
Mark Minasi
Chief cook and bottle washer
    
USA
10658 Posts
Status: offline |
Posted - 08/13/2011 : 09:56:44 AM
|
I don't know PS well enough to answer the question, but I DO know that you can run regular old "internal" CLI tools in Powershell by prefixing them with "cmd /c" (I think that's right), so why not just use
rd /s /q <name of folder>
It would delete the folder and any files/subfolders. |
Mark tweetin' at mminasi |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/14/2011 : 01:45:45 AM
|
quote: Originally posted by Mark Minasi
I don't know PS well enough to answer the question, but I DO know that you can run regular old "internal" CLI tools in Powershell by prefixing them with "cmd /c" (I think that's right), so why not just use
rd /s /q <name of folder>
It would delete the folder and any files/subfolders.
Thanks Mark, but sadly doesn't help me. :) In my original note, I indicated that I have a batch file that does exactly that, and it works. Pasted below...
From good old batch, everything works fine.
@echo off
set LocalProfile="\\%2\c$\Users\%1"
echo Deleting profile directory [%LocalProfile%]
rd /s /q %LocalProfile%
But my purpose here is not to simply make this work by any means. It's already working in another language. My purpose here is to learn Powershell, and more importantly to do things the "Powershell way."
"RD /S /Q" is not the Powershell way, that's the "DOS" (for lack of a better term) way. If the answer to every one of Powershell's shortcomings is just "shell out to a language that works" well, I'll just stay in those languages. :)
Sooo....does Powershell have a native way to "deltree" or "rd /s /q" a profile folder under C:\Users? Again, based on my testing, it appears to be the legacy "Application Data" junctions that trip up Powershell's "Remove-Item" method.
Note: I have only tried this while accessing a remote machine via "c$". I had thought about maybe UAC playing a part, but if that were the case, I'd think "rd /s /q" would die as well. I will have to test this on the local box and see if I get the same results.
|
Edited by - sixdoubleo on 08/14/2011 01:48:02 AM |
 |
|
|
jmarquart
Seasoned But Casual Onlooker

50 Posts
Status: offline |
Posted - 08/16/2011 : 6:38:32 PM
|
Here are two ways to do this natively from powershell:
rd c:\DirectoryName -rec -for
or
Remove-Item -Recurse -Force "C:\DirectoryName"
sixdoubleo - I'm having the same problems as well. I get path to long errors and problems with certain files in the profile. The above seems to work well with non-profile directories, but does not work with profile directories.  |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/17/2011 : 12:50:22 AM
|
quote: Originally posted by jmarquart
Here are two ways to do this natively from powershell:
rd c:\DirectoryName -rec -for
or
Remove-Item -Recurse -Force "C:\DirectoryName"
sixdoubleo - I'm having the same problems as well. I get path to long errors and problems with certain files in the profile. The above seems to work well with non-profile directories, but does not work with profile directories. 
Thanks for confirming. Glad to know I"m not just crazy! Like I said above, it's the junctions. Remove-Item doesn't know what to do with junctions.
I find it pretty silly that Powershell made it out the door and is now at 2.0 and nobody in the history of Powershell, especially with all the noise about how brilliant it is...not one person tried to delete a User profile directory with it. Kind of a common task. :)
I'm hoping it's just my own ignorance and one of the experts chimes in and says "No, Dave...you forgot the "-DoubleDogForce" switch...common mistake with PoSH newbs!!" and that fixes it.
|
Edited by - sixdoubleo on 08/17/2011 04:20:23 AM |
 |
|
|
Nobody
Here To Stay
 
USA
184 Posts
Status: offline |
Posted - 08/17/2011 : 11:22:10 AM
|
| I'm patiently waiting for an answer too. I was recently tripped up on exceeding path length while searching PC's for files. |
aka - Matt www.SnowTrek.org |
 |
|
|
lady_mcse
Old Timer
  
634 Posts
Status: offline |
Posted - 08/18/2011 : 1:03:56 PM
|
Um, so I have a question ... why would you want to?
By that I mean that in my days of supporting NT\2000\XP, I always found that BAD things happen when you just try to yank the user profile data. First off even in the GUI and just trying to do a right-click+delete on c:\documents and settings\userprofile, you'd get hung up on some of those same sub-areas deep under application data. So you could do a cacls or take ownership on the whole structure and try to delete and delete again, and have to drill down to the things that were still in use or the path-to-long-to-delete problem would come up (particularly temporary internet files and files associated with Outlook attachments).
So my own "best practice" was always to use the System Properties to review the profiles, and do the delete from that interface. That would guarantee that the OS was handling all the deleting and it almost always worked. Sometimes one would seem to be not deleteable, but my rusty brain isn't remembering how I'd fix it.
Then at my previous job, my boss introduced me to delprof ... http://www.microsoft.com/download/en/details.aspx?id=5405 But I was doing less end-user desktop support so I didn't really use it much. Been on Win7 for a while now too, and doesn't look from a quick search like there's a delprof for Win7.
Here's another article that kind of supports what I'm saying ... reasons you don't want to just manually rip the supporting files out out from underneath the profile, leaving all the registry bits in place. http://www.sepago.de/helge/2008/10/16/deleting-a-local-user-profile-not-as-easy-as-one-might-assume/
So where does this get us? Me, miss know-very-little-about-powershell, is wondering if there's actually a command that accomplishes the same thing that Delprof used to - delete the files AND the registry bits.
Guess I'm giving more questions than answers. :-)
|
Anne O'Day MCITP: SharePoint 2010 |
 |
|
|
lady_mcse
Old Timer
  
634 Posts
Status: offline |
Posted - 08/18/2011 : 1:05:19 PM
|
| ? |
Anne O'Day MCITP: SharePoint 2010 |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/18/2011 : 5:10:55 PM
|
quote: Originally posted by lady_mcse
Um, so I have a question ... why would you want to?
By that I mean that in my days of supporting NT\2000\XP, I always found that BAD things happen when you just try to yank the user profile data.
... ...
So my own "best practice" was always to use the System Properties to review the profiles, and do the delete from that interface. That would guarantee that the OS was handling all the deleting and it almost always worked. Sometimes one would seem to be not deleteable, but my rusty brain isn't remembering how I'd fix it. Here's another article that kind of supports what I'm saying ... reasons you don't want to just manually rip the supporting files out out from underneath the profile, leaving all the registry bits in place. http://www.sepago.de/helge/2008/10/16/deleting-a-local-user-profile-not-as-easy-as-one-might-assume/
So where does this get us? Me, miss know-very-little-about-powershell, is wondering if there's actually a command that accomplishes the same thing that Delprof used to - delete the files AND the registry bits.
Guess I'm giving more questions than answers. :-)
I think it's perfectly acceptable to ask "why in the he** would you even want to do that?" Deleting a profile directory is sometimes necessary and perfectly safe, *IF* you know what you're doing and how it all works. In one of your URL's, the author has a section that says "The Right Way". Note one of the bullet points says to take care of the "ProfileList" entry in the registry. I'm doing that, FYI. So any of the bad demons that occur when you merely delete a user's local profile (Like creation of a TEMP profile) are addressed.
Anyway to answer your question....the code snippet I posted is part of an overall troubleshooting script whose job it is to essentially "clear" a user's profile when they become corrupted, mangled, out of whack, or otherwise problematic. Technicians execute this script and it does several things....quickly and efficiently without that person needing to know how to do these things manually. (Trust me...this started out as a "How to Clear a User's Roaming Profile" procedure that we found very few people could follow correctly, so like many things in our organization it became an automated repeatable script that does it right every time.
This script is run remotely from a help desk admin workstation and does the following:
1. The user is instructed to reboot the computer and leave it at the logon screen. (This releases the profile so it can be deleted. Permission issues which you eluded to are also not an issue because on our domain permissions are established allowing the help deks staff the rights to do this. Further, because it's happening remotely (\\?\C$) UAC is not in the way. It's typically UAC wanting you to take ownership of user profile folders. Accessing via c$ remotely eliminates this. 2. The script is executed by the technician supplying the UserID and workstation. 3. Active Directory is queried and the roaming profile path for the user is retrieved. 4. The roaming profile is robocopy'd to a backup directory, so that profile elements can easily be restored after the fact. Then the CONTENTS of the roaming profile directory (and all subdirectories) is deleted. 5. It remotely enumerates the HKLM\Software\Microsoft\Windows NT\ProfileList key on the user's machine, and deletes the GUID for that user (this is the equivalent of what happens behind the scenes when you use the GUI method of deleting a profile or delprof, or similar utilities). 6. And then finally it deletes the cached copy of the user's profile on their workstation. This is necessary because the local/cached copy of the profile contains areas that are NON-roaming (i.e., "Local|LocalLow" on Vista/W7 or "Local Settings" on XP). All of this needs to be deleted in order truly have a clean/fresh logon.
After running this script, you're left with a user who has an empty roaming network profile (with a backup), and no trace whatsoever of a cached local profile on the machine, and no references in the registry to a profile either. A technician can run this command "ClearProfile JDoe Computer34" and within a couple seconds it creates a truly "clean" logon for JDoe as if that person has never logged on before.
It works and HAS worked for years as a troubleshooting tool at our help desk, but it's simply written in a different language currently. As part of an overall move to get our administrative scripts written in Powershell, this particular script was in need of a couple modifications, so I thought it was the perfect time to rewrite it in Powershell.
So anyway, hopefully that answers the "why would you even want to do that anyway?" question. :) Our environment is large, and very distributed, so a lot of administration is done remotely, and often by staff who aren't as skilled as in some organizations. This "ClearProfile" command is a bit of a last-resort type tactic that works well in cases where applications have corrupted portions of the profile, or even upgrading (or rolling back) an application can cause profile problems. There are instances where uses have got viruses/malware that causes damage to the Profile. Even an unsuccessful logoff over a remote connection can sometimes leave a USER.DAT or other file not fully closed, whereby your only course of action is to clear out the profile and start fresh. A corrupted profile is the cause of a lot of problems that get mistaken as problems with the machine. You'd be surprised how many workstations get unnecessarily re-imaged when simply starting the user with a new profile would have corrected it. Our help desk staff have this tool, and at least a hundred others like it, available for those type of situations.
So anyway, as can often happen when you're asking for help on a forum, TOO many details can detract from the actual problem, so I left out the 50 other details and focused on just the one I was wondering about...."why can't Powershell delete stuff?" :) |
Edited by - sixdoubleo on 08/18/2011 5:27:03 PM |
 |
|
|
Rambler
Major Contributor
   
Czech Republic
948 Posts
Status: offline |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 08/18/2011 : 5:48:09 PM
|
quote: Originally posted by Rambler
Might have something to do with the fact that the -recurse parameter is not working properly - as is stated in the help. Actually this bug has been around since v1, but MS didn't bother to fix it for some reason.quote: -Recurse [<SwitchParameter>] Deletes the items in the specified locations and in all child items of the locations.
The Recurse parameter in this cmdlet does not work properly.
More at https://connect.microsoft.com/PowerShell/feedback/details/549039/remove-item-recurse-does-not-work-properly-is-faulty (+suggested workaround).
Thanks, I saw that in the help (in my second post) but good to know there are 7 others (plus the two here) who can reproduce the problem. :)
You said there was a suggested workaround...I didn't see one. It says Workarounds(0).
|
 |
|
|
Rambler
Major Contributor
   
Czech Republic
948 Posts
Status: offline |
Posted - 08/19/2011 : 02:46:44 AM
|
| I thought the code using gci -recurse -force | remove-item -force would work, but just tested it and it doesn't delete all folders. |
 |
|
|
Xenophane
Honorable But Hopeless Addict
    
Denmark
3070 Posts
Status: offline |
Posted - 08/19/2011 : 07:07:13 AM
|
Try to do a:
Get-Help Remove-Item -Parameter Recurse
-Recurse [<SwitchParameter>] Deletes the items in the specified locations and in all child items of the locations.
The Recurse parameter in this cmdlet does not work properly.
Required? false Position? named Default value Accept pipeline input? false Accept wildcard characters? false
|
Microsoft Powershell MVP
SIG> George Bernard Shaw : The power of accurate observation is commonly called cynicism by those who have not got it. </SIG>
You can read my blog at www.xipher.dk |
Edited by - Xenophane on 08/19/2011 07:07:49 AM |
 |
|
|
jmarquart
Seasoned But Casual Onlooker

50 Posts
Status: offline |
|
|
Playwell
Honorable But Hopeless Addict
    
Netherlands
4819 Posts
Status: online |
Posted - 04/26/2012 : 03:52:57 AM
|
What's wrong with using a simple tool like delprof?
|
'People who think they know everything are a great annoyance to those of us who do. ' Quote by Isaac Asimov

|
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 04/26/2012 : 1:24:03 PM
|
quote: Originally posted by jmarquart
I agree with lady_mcse - just deleting the user profile directory like a regular directory is not a good idea.
Why not? If you do it correctly (as in delete the profile directory and delete the corresponding "ProfileList" entry from the registry) then what's the problem? This is exactly what happens when you do it through the GUI.
|
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 04/26/2012 : 1:30:22 PM
|
quote: Originally posted by Playwell
What's wrong with using a simple tool like delprof?
Again, I wasn't looking for a solution to delete profile folders...I already have other ways to do this whether it be another scripting language, the RD command, or what have you.
I'm trying to use powershell to do things I currently do in other languages and wanted to find out why it can't delete folders...a seemingly simple task. |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 04/26/2012 : 2:10:36 PM
|
quote: Originally posted by jmarquart
Anyway found the following link on one way to delete user profiles using Powershell (and it works well):
Powershell: Script to delete Windows User Profiles on Windows 7/Windows 2008 R2
http://techibee.com/powershell/powershell-script-to-delete-windows-user-profiles-on-windows-7windows-2008-r2/1556
By the way thanks for this script. Always good to see alternate methods of doing things.
He's using the WMI method to delete the folder as well as the ProfileList entry. I tried this method and while it does work, it only works when everything is perfect. If you have an orphaned ProfileList entry (where there is no corresponding local profile folder) it sometimes fails. Also in cases where somebody has deleted the profile through the GUI and the folder still partially exists (as in cases where it was in use still) this method doesn't work 100% of the time.
The only sure fire method I found was to actually enumerate ProfileList and then RD /S /Q the folder. This way you can also look for ".TEMP" entries as well.
Here's my script which has been in use for about 6 months now and works great (albeit using RD /S /Q to get around the -Recurse bug)
param ($strComputer, $strUser, $strOpMode)
If (($strComputer -eq "") -or ($strUser -eq ""))
{
Write-Host
Write-Host
Write-Host "ClearLocalProfile - Deletes cached local profile directory from a computer and clears the reference from the registry"
Write-Host
Write-Host "Usage: .\ClearLocalProfile.ps1 <Computer> <UserID>"
Write-Host
Write-Host "ERROR: Incorrect number of arguments."
Exit 1
}
$strLocalProfile = "\\$strComputer\c$\Users\$strUser"
$strLocalProfileZ = "\\$strComputer\c$\Users\z$strUser"
If ($strOpMode -eq "DELETE") { Write-Host "Deleting local profile directory from computer $strComputer"
& cmd.exe /c RD /S /Q $strLocalProfile }
Else {
if (Test-Path -path $strLocalProfile) {
Write-Host "Renaming local profile directory to $strLocalProfileZ"
Rename-Item -Path $strLocalProfile -NewName $strLocalProfileZ }
}
$strRegBase = "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList"
$objReg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("LocalMachine", $strComputer)
$regKey=$objReg.OpenSubKey($strRegBase)
$regKey.GetSubKeyNames() | foreach { $regSubKey = $objReg.OpenSubKey("$strRegBase\\$_")
$strProfilePath = $regSubKey.GetValue("ProfileImagePath")
$strProfileUserName = $strProfilePath.Split("\")[-1]
If (($strProfileUserName -eq $strUser) -or
($strProfileUserName -eq "TEMP") -or
($strProfileUserName -eq "$strUser.TEMP"))
{ Write-Host "Deleting Key : $regSubKey"
$objReg.DeleteSubKeyTree("$strRegBase\\$_") }
}
Edit: Sorry about the spacing...all the indentation got messed up in the copy/paste from Notepad++...
|
Edited by - sixdoubleo on 04/26/2012 2:15:59 PM |
 |
|
|
JSCLMEDAVE
Administrator
    
USA
6114 Posts
Status: online |
Posted - 04/26/2012 : 2:14:27 PM
|
| You know, with 10 Write-Host you just killed 10 puppies... <g> |
Tim-
“This too shall pass" |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 04/26/2012 : 2:17:24 PM
|
quote: Originally posted by JSCLMEDAVE
You know, with 10 Write-Host you just killed 10 puppies... <g>
Haha...uh-oh, did I just show my Powershell n00b status by using Write-Host?  |
 |
|
|
JSCLMEDAVE
Administrator
    
USA
6114 Posts
Status: online |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
|
|
JSCLMEDAVE
Administrator
    
USA
6114 Posts
Status: online |
Posted - 04/27/2012 : 09:46:14 AM
|
My co-worker emailed me this great tid bit.
Chris Duck http://blog.whatsupduck.net/
Tim
Remove-Item is able to delete a junction. You can test this by creating one (using cmd.exe, PowerShell cannot create them natively, even .Net doesn't support creating them) and then deleting it in PowerShell:
cmd.exe: > md c:\temp\junction > cd c:\temp\junction > md real > mklink /d fake real
> dir 04/26/2012 03:51 PM <SYMLINKD> fake [real] 04/26/2012 03:51 PM <DIR> real
powershell.exe: > cd c:\temp > Get-ChildItem junction -recurse Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 4/26/2012 3:51 PM fake d---- 4/26/2012 3:51 PM real
> Remove-Item junction -recurse -force
You have to use "-Force" to remove a junction, and if you forget it PowerShell will tell you so. The problem with the "Application Data" folder is not that it is a junction, but that it is: 1) marked as Hidden and System 2) it has an ACL that denies everyone ReadData
To fix both of those issues…
powershell.exe: > #First make the folder visible > Set-ItemProperty -Path "c:\users\someuser\Application Data" -Name Attributes -Value "Normal" > dir c:\users\someuser
Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 4/21/2011 5:15 PM Application Data d-r-- 4/21/2011 5:15 PM Contacts d-r-- 4/21/2011 5:16 PM Desktop d-r-- 4/21/2011 5:15 PM Documents d-r-- 4/21/2011 5:15 PM Downloads d-r-- 4/21/2011 5:15 PM Favorites
> #Next remove the deny everyone ReadData ACE from the ACL > $acl = Get-Acl "c:\users\someuser\Application Data" > $acl.access
FileSystemRights : ReadData AccessControlType : Deny IdentityReference : Everyone IsInherited : False InheritanceFlags : None PropagationFlags : None
FileSystemRights : FullControl AccessControlType : Allow IdentityReference : NT AUTHORITY\SYSTEM IsInherited : True InheritanceFlags : ContainerInherit, ObjectInherit PropagationFlags : None
>#Remove all the deny entries (there is only one on my system) > $acl.access | where-object {$_.AccessControlType -eq "Deny"} | Foreach-object { $acl.RemoveAccessRule($_) } True
>#Now save the ACL back on the folder object ># If you use Set-ACL it complains because the owner can't be System, ># So instead use the "SetAccessControl" method on the FolderInfo object (or you could change the owner on the $acl and use Set-ACL) > (Get-Item "c:\users\someuser\Application Data").SetAccessControl($acl)
> #Now you should be able to use Remove-Item to delete the folder > Remove-Item "c:\users\someuser\Application Data" -Force
Chris
|
Tim-
“This too shall pass" |
 |
|
|
sixdoubleo
Major Contributor
   
USA
859 Posts
Status: offline |
Posted - 04/27/2012 : 10:02:43 AM
|
Excellent, Tim...now we're getting somewhere. ;)
I'd suggested in the 3rd or 4th post that it was the junctions tripping up Remove-Item...but could never understand why Remove-Item could delete junctions *I* create, but not delete the "factory" junctions in a users profile...the Deny ACL.
What's ironic is that I have another script that for a certain set of users redirects the legacy "My Documents" junction...and in doing so, I remove the explicit Deny ACL, then delete the junction, then recreate the junction, then re-add the Deny. So I can't believe I'd never tried that. ;)
Good find!
|
 |
|
|
JSCLMEDAVE
Administrator
    
USA
6114 Posts
Status: online |
Posted - 04/27/2012 : 10:05:08 AM
|
Jeff is working on a reply as well.
All credit for my post goes to Chris. He has Amazing Powershell skills... |
Tim-
“This too shall pass" |
 |
|
|
JeffWouters
Here To Stay
 
Netherlands
147 Posts
Status: offline |
Posted - 04/27/2012 : 10:10:36 AM
|
@Tim: Great post! Good explanation and very nice use of piping :-) @SixDoubleO: Tim explained it all... nothing to add to his solution. I see in your first post in this topic that you delete the directory from a network path (\\$Computer\c$\Users\$UserID for example). In my experience this can be the cause of the script not working as expected. I always execute the code on the device it's targetting (that's the strength of PowerShell remoting). By then you can use Tim's code about correcting the ACL and stuff... if you would do it on a network path it would require some creative scripting where executing the code through remoting makes it a lot easier :-)
Note: Or use explicit remoting... |
Greetsz, Jeff. |
Edited by - JeffWouters on 04/28/2012 12:36:31 PM |
 |
|
|
teejay58
Welcome Newcomer
USA
3 Posts
Status: offline |
Posted - 05/16/2012 : 6:02:09 PM
|
| Thank you! I've been banging my head on the wall for months, looking for this answer. Thank you so much! |
 |
|
| |
Topic  |
|