How to delay the move-item

[scharique]

Hello,I have the following script that I use to gather gpresults from remote servers copied on to my box, it seems there is not enough time for gpresult to run and export the results in the text file before the move-item happens. How can I introduce some time delay ?$destination = "c:psexportsrsop"# Change D:servers.txt to your input file's pathname.$servers = get-content c:psexportsame_servers.txtforeach ($s in $servers){ $result = ([WmiClass]"$sROOTCIMV2:Win32_Process").create("cmd /c gpresult > c:$s-rsop.txt") switch ($result.returnvalue) { 0 {"$s Successful Completion."} 2 {"$s Access Denied."} 3 {"$s Insufficient Privilege."} 8 {"$s Unknown failure."} 9 {"$s Path Not Found."} 21 {"$s Invalid Parameter."} default {"$s Could not be determined."} } if ($result.returnvalue -eq 0) { [diagnostics.process]::start("powershell", "-command & {move-item -path $sc$$s-rsop.txt $destination -force}").waitforexit(19000) }}

[jvierra]

Hah -found it.

Code: Select all

function Start-Process(
        [string]$pfile = 'cmd.exe',
        [string]$arguments = '/c dir'
    ){
    $p = New-Object System.Diagnostics.Process;
    $p.StartInfo.UseShellExecute = $false;
    $p.StartInfo.RedirectStandardOutput = $true;
    $p.StartInfo.FileName = $pfile;
    $p.StartInfo.Arguments = $arguments
    [void]$p.Start();
    $p.WaitForExit();
    $p.StandardOutput.ReadToEnd();
}

[jvierra]

Just replace all of your code with this. YOu don't need to use WMI or the process you are using. Just use this function to start both processes.

YOu seem to be at a loss as to what yhou ae doing. YOu are using PowerShell ot execute both DOS commands and PowerShell commands. You should just use PowerShell for all commands. It is safer, easier to code and faster.

[jvierra]

Here is teh command for remote gpresult.

gpresult /S $s > file.txt

where $s is the remote server name.

The file will be created on the local machine. No need for remote process and n need for PowerShell. This can run from any prompt PowerShell or CMD. No need to move any files.

The code will wait if it is just run from the script. All local processes always wait unless otherwise requested.

WHoever wrote your original code didn't know much about WIndows or PowerShell so they thought GPRESULT had to be run remotely - it doesn't.

[scharique]

You are correct, the logic to go after rsop info via remote gresult was completely incorrect. I had never taken the time to look at the syntax for gpresults and realized it could be run against remote systems. The original code came from the link below where the author is doing the same for ipconfig results. I will try out what you suggested and report back.Thanks againhttp://windowsitpro.com/article/articleid/101432/use-powershell-to-execute-commands-on-remote-machines.html

[scharique]

Have you tried this ?$servers=gc c:servers.txtforeach ($s in $servers) {gpresult /S $s > c:$-rsop.txt}The resultant files are created but are empty.

[jvierra]

sharique - you didn't see it yet?

You forgot teh 'S' in $s.

I have a rule for myself. I will have on dumb mistake for every three lines of code. That is why I make an issue out of careful naming of things. Wven -> $server in $servers is not very good a sit is hard to tell the difference betweenthe two variables at first. This -> $server in $serverList would be better.


It really all a matter of good coding habits that helps us to avoid simple mistakes. The simple mistakes are usually the hardest ones to find.



jvierra2009-10-09 15:43:32

[jvierra]

Here is an example of RSOP (GPRESULT) to a file using only script.

Code: Select all

Set oGpm = CreateObject("GPMGMT.GPM")
Set oGpConst = oGpm.GetConstants()

Set oRSOP = oGpm.GetRSOP( oGpConst.RSOPModeLogging, "" , 0)
strpath = Left(Wscript.ScriptFullName,   InStrRev(Wscript.ScriptFullName,"", -1, vbTextCompare) )

oRSOP.LoggingFlags = 0
oRSOP.CreateQueryResults()
Set oResult = oRSOP.GenerateReportToFile( oGpConst.ReportXML ,  strPath & "rsop.xml")

oRSOP.ReleaseQueryResults()

More information is available here:
http://gallery.technet.microsoft.com/Sc ... 9902ec2580

Other formats and filters area available. All RSOP data can be posted to a database such as SQLServer, Oracl, MSAccess or Excel via scripting techniques.

These techniques are excellent for generating compliance reports across a domain.

[jvierra]

Using the GPM RSOP object:

Code: Select all

function Get-Results( [string]$pc=$env:computername){
    begin{
        $gpm = New-Object -ComObject GPMGMT.GPM
    } #END-BEGIN
    process{
    
     foreach($x In $input){
      $temp = $x
     }
     if($temp){$pc=$temp}
        $rsop= $gpm.GetRSOP( $GpConst.RSOPModeLogging, "" , 0)
        $rsop.LoggingComputer = $pc
        $rsop.LoggingFlags = 0
        $rsop.CreateQueryResults()
        $result = $rsop.GenerateReportToFile( $GpConst.ReportXML , "$pwd$pc-rsop.xml")
        $rsop.ReleaseQueryResults()
     notepad $pwd$pc-rsop.xml
     
    } # END-PROCESS
    end{
    } #END-END
}

USAGE:

# local machine computer settings
Get-Results
# any machine (XP or later) computer results
Get-Results "MyHost1"
# list of hosts
$serverlist | Get-Results

Results are written to an XML file and displayed in notepad for verification. File name is decorated with machine name.

Variations can be obrtained by seting the arguements to the GPM object.


File can be output as HTML with one simple change.


For other information and books on this topic see:
http://www.sapienpress.com/ad.asp

Jeff Hicks has done much along these lines and reports on how to use some of the free CmdLets available for managing GP and AD.


jvierra2009-10-11 11:01:20

[scharique]

Thanks for all your help.I did notice the mistake I had made in the following code.$servers=gc ame_servers.txtforeach ($s in $servers){gpresult /S $s > c:$s-rsop.txt}However, it seems that the idea to use GPRESULT for remote servers does not work as discussed. The output files are empty even though the command was run under a DA security context.I see that you have put forth WMI and COM solutions to this but earlier we had discussed that when there is a native functionality we do not revert to engineering a new wheel. I will try out your latest script on this thread, it seems promising.