.NET Core CLR is now available for OS X and a new Core CLR version of PowerShell is going to have to be used to manage those end points, as I understood it.
Let see what happens then, PowerShell and PowerCLI for Linux and OSX would be sweet
I agree 100%
@alanrenouf Do you know if it's possible to reuse/pass an authenticated PowerCLI session into a child .NET runspace, in order to be used for async' script execution?
I normally pass the
Whoops hit enter too fast, I normally pass the session secret and use that to connect to the vcenter server $session = $global:DefaultVIServer.sessionsecret
Then connect-viserver VC -session $session
If your doing this for jobs go careful, I had vCheck working with jobs but it takes a lot of resources from the client machine and kills the process.
I mean specifically for vCheck that is, not jobs in general
@alanrenouf Cool; that's what I was thinking, as far as method. I thought about using it for vCheck, but I am working on a reasonably high priority request and I think seperate .NET runspaces could potentially eliminate some unnecessary overhead. That said, I'm going to keep a closer eye out on resource consumption, per your comment. Thanks a lot :thumbsup:
Anyone available for assistance configuring this to run as scheduled task. I must be missing something, or at least right direction for debug?
The usual problem for running as a scheduled task is if you have the vCenter Services/Events plugins enabled and running as a different user. You need to run Powershell as the user that is running the task and run vCheck manually first, this will create the credential file.
I see that this script is meant to be used for only specific uses vsphere, exchange, vcenter audit... Why not make this more generic
And let the plugins fetch results from: exchange, vsphere, ADS, SQL, and such?
This is definitely on the to do list, but requires quite a bit of work to do properly. Technically this is possible now, if you structure your plugins folder appropriately.
Exactly, it works at the moment but what would you want to see @Proxx ? an initial selection of which product to check?
The HTML framework was adapted along time ago to basically make it easy to report on any PowerShell script that creates an output
Personally I would like to see the GUI config completed as in this case it would be so much easier to configure, especially as the plugins are now getting more and more.
Yeah, the config GUI and changes to the settings (to facilitate easier updates) would be definitely the top of the list. This is more of a nice to have, and could trim down the execution time and resource usage by only fetching information that is required by plugins.
Maybe we should share a PowerShell studio project in the Github repo as well so we can start building the GUI, I have a few ideas
the Get-HMTLTable accepts $FormatRules. can i use this parameter from a plugin?
sorry must have overlooked the $TableFormat :-1:
Has anyone thought about doing stuff multithreaded? Especially 79 - find uncontrolled snapshots
This does take a long time to complete
Yeah, it's certainly something worth considering at some point.
I have done multi-processing for 79 - find uncontrolled snapshots and other plugins.
Running with all plugins takes considerable amount of time