Exchange Log Collector - Removed legacy code and handled new logging#951
Conversation
Added the ability to inject $VerbosePreference and $DebugPreference into the remote script block to allow that information to be displayed when the Preference is properly set. You can also include custom using parameters and script blocks to be injected into the main remote script block.
Moved the logic used for injecting the script block to its own function to make it easier to redo Start-JobManager.
Removed Write-InvokeCommandReturnHostWriter and Write-InvokeCommandReturnVerboseWriter to avoid a odd dependency for those functions.
Placed the files in the correct location as no longer in extern
Removed this dependency for the old logical of how to handle Write-Verbose type data in a script
Switched how the callers of Start-JobManager to account for the new functionality of it. However, still need to add in the debug logic back into it.
If a function is inside of a function that is dot loaded, the parent includes that original dot loaded function. Not a common scenario to address for. However, in case something else rises up, this logic should be able to handle it.
Added the ability to do remote logging on the functions that get called individually and where we want to have logging enabled for them.
Besides the Write-ScriptHost and Write-ScriptDebug, other functions have the dependencies set in the file that uses them.
To avoid issues of making sure that all callers know to do something like this "[$env:ComputerName] : some message" prior to calling Write-Host. You can just set the manipulate object action to avoid repetitive actions.
To avoid issues of making sure that all callers know to do something like this "[$env:ComputerName] : some message" prior to calling Write-Verbose. You can just set the manipulate object action to avoid repetitive actions.
Added the functions that are able to manipulate the string prior to calling the native Write-Host or Write-Verbose. This is critical to have within the Invoke-RemoteFunctions to be able to see the computer that the Write-Verbose or Write-Host is coming from.
Need to be able to set VerbosePreference in remote context so Write-Verbose gets called and displays on screen.
Right now, don't need to have Invoke-ScriptBlockHandler use this code, so just going to move it into Exchange Log Collector for the time being.
This shouldn't have been in there to begin with
On single server execution, we don't spin up a second session to run the majority of the code. Therefore, to keep things looking the same in both context, need to revert the SetWriteHostManipulateObjectAction to not take any actions.
should only need to do this for Write-Verbose context
bill-long
left a comment
bill-long
left a comment
There was a problem hiding this comment.
This looks fine for now. Compress-Folder and New-Folder (does that even need to exist?) should be looked at in a future PR. They look like old code that could use some work.
Yep, will optimize that code here in a different PR. New-Folder still needs to exist as it is called a few different times and this way it will always do the Test-Path prior to attempting to create the folder to avoid errors from occurring. |
That's what -Force does.
It either creates the folder (and every other folder in the path you specified that doesn't already exist), or returns the folder if it already exists. |
Was not aware of the Force switch. |
2 participants
Reason:
Need to remove the old legacy code like
Write-VerboseWriterandWrite-ScriptMethodVerboseWriterwhere it was used instead of the override option that we now have withWrite-Verboseand still being able to call the nativeWrite-Verbosewithin the override method.Fix:
Updated code enough to remove the old functions and be able to handle logging while inside of a
Invoke-Commandto be returned on the pipeline to give you better error context.Validation:
Tested within lab with multiple servers and single server.