Question: How can I see all open ETW sessions, including their root paths? I'd expect some PowerShell command like Get-EtwTraceSession, but I don't see any.
Background
I work with EventTracing API, and occasionally find myself out of sessions because of stuff installed on my machine.
This answer tells me I can run logman -ets to see the list of sessions, and then logman stop <SessionName> -ets to stop some sessions. That's good, but how can I know what a cryptically-named session is?
I can tediously query individual sessions, and get a clue from their root path:
> logman -ets SensorFramework-{c4eaa67d-dd9a-4fce-0002-000000000000}
(...)
Root Path: C:\windows\CCM\SensorFramework <<<< Aha! CCM = System Center Configuration Manager
But I'm looking for a more convenient solution.
Solution: Do it through WMI:
Get-WmiObject -Class MSFT_EtwTraceSession -Namespace ROOT/Microsoft/Windows/EventTracingManagement `
| sort -Property LocalFilePath `
| ft -AutoSize -Property Name,LocalFilePath
Note: This only sometimes works (don't know what determines when), and sometimes only shows one session - Circular Kernel Context Logger. When not working, the Get-EtwTraceSession also shows only this session, presumably because it uses the same WMI object underneath.
Related
Can anyone suggest a reasonably practical and efficient way to load 1.2 million test items into a SharePoint Online list?
Background: We've decided to build a new application on top of SharePoint Online. Other application architecture options have all proved non-viable for various reasons. The application will use several SharePoint lists for persistence, one of which will be large, about 1.2 million items at peak. (Yes, we're planning ways to handle the 5000 item view limit.) To test viability of the architecture (including those view limit tactics) we need to create 1.2M test items in a list. Nothing we've tried has been practical:
Tried making POST calls to the REST API, with 5 concurrent threads so it will finish in a reasonable time. This fails after a bit with a HTTP 429 "Too many requests".
Tried uploading a spreadsheet with 1.2M rows. This fails at 130K entries each time, and I don't see a practical way to either upload / append to an existing list, nor to append items from one list to another existing list.
Tried running a Workflow (SharePoint 2013 variety, if that matters). This works but runs way too slow single threaded and I'm hesitant to try multiple concurrent workflows because this is a shared environment and if I trash the server that would be way not good.
Thanks in advance for any pointers!
You could try to use pnp powershell to add more than 1 million items.
$username = "amos#contoso.onmicrosoft.com"
$password = "password"
$cred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $userName, $(convertto-securestring $Password -asplaintext -force)
Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/dev -Credentials $cred
$ListName ="testn"
for($i=0;$i -lt 1000001;$i++){
Add-PnPListItem -List $ListName -Values #{"Title" = "test";}
}
Fastest way to load and process items from SPO using PnPPowershell goes something like following. Idea is to not initialize the items collection in any variable and directly process the items by page size.
Get-PnpListItem -List "{ListName}" -Fields "Field1","Field2","Fieldn" -PageSize 5000 | % {$i=0}{
% {$i=0}{
Do not move { to next line, I know it's weird but if you move, then good luck.
$item = $_
#Do your stuff with $item
Write-Host $item.Id
}
I have an array $array with many elements, an example looks like this:
ProfileID : 100
UID : 17
Name : SharePoint
Description : SharePoint Server Description
Now I am trying to filter by Name property, string to match is:
$string
SharePoint Policy Assignment
I have tried:
$array | Where-Object {$_.Name -like "$string"}
no match
$array | Where-Object {$_.Name -like "$string*"}
no match
$array | Where-Object {$_.Name -match "$string"}
no match
Is this possible using PowerShell? What am I missing?
The -like operator in PowerShell is used for a wildcard match, so you need to use the wildcard character, the asterisk, *.
Imagine this scenario, where I'm trying to match a particular Windows Service.
$svcs = Get-Service | Select-Object -first 15
C:\temp\blog> $svcs
Status Name DisplayName
------ ---- -----------
Stopped AJRouter AllJoyn Router Service
Stopped ALG Application Layer Gateway Service
Running AMD External Ev... AMD External Events Utility
Stopped AppIDSvc Application Identity
Running Appinfo Application Information
Stopped AppMgmt Application Management
Stopped AppReadiness App Readiness
Stopped AppVClient Microsoft App-V Client
Stopped AppXSvc AppX Deployment Service (AppXSVC)
Stopped aspnet_state ASP.NET State Service
Stopped AssignedAccessM... AssignedAccessManager Service
Running AsSysCtrlService ASUS System Control Service
Running AudioEndpointBu... Windows Audio Endpoint Builder
Running Audiosrv Windows Audio
Running AUEPLauncher AMD User Experience Program Launcher
To use the -Like operator to get a match, I have to provide a Wildcard Character, like this.
$svcs | Where-Object Name -like App*
Status Name DisplayName
------ ---- -----------
Stopped AppIDSvc Application Identity
Running Appinfo Application Information
Stopped AppMgmt Application Management
Stopped AppReadiness App Readiness
Stopped AppVClient Microsoft App-V Client
Stopped AppXSvc AppX Deployment Service (AppXSVC)
Try your operation using a WildCard, and I bet it will work :)
One other thing I noted, your $string is equal to SharePoint Policy Assignment, but the column you're comparing on of .Name is just SharePoint.
To complement FoxDeploy's helpful answer:
With collections that are already are in memory or easily fit, you can use member-access enumeration for a more convenient syntax that also results in much faster execution:
#($array.Name) -like $string # returns sub-array of matching elements
-like, when given an array as the LHS, acts as a filter: only those array elements that match the wildcard expression on the RHS are returned (also as an array).
Note the need for #(...) to ensure that $array.Name is an array, because a single-element array would result in the .Name property getting returned as a scalar (a single string), in which case -like would return a Boolean ($true or $false) rather than acting as a filter.
Also note that many PowerShell cmdlets directly support wildcard expressions as parameter values:
Taking Get-Service as an example, its (implied) -Name parameter supports wildcards:
Get-Service *router* # returns all services whose Name contains "router"
To determine a given cmdlet parameter's wildcard support:
PS> Get-Help Get-Service -Parameter Name
-Name <String[]>
Specifies the service names of services to be retrieved. Wildcards are permitted. By default, this cmdlet gets all of the services on the computer.
Required? false
Position? 1
Default value None
Accept pipeline input? True (ByPropertyName, ByValue)
Accept wildcard characters? false
It should be the Accept wildcard characters? value being true that indicates support for wildcard expressions, however, this is unfortunately not reliable, so also check the parameter description; here, the descriptin part Wildcards are permitted provides the information.
GitHub issue #4716 describes the problem and asks to make the programmatic discoverability of wildcard support reliable.
I am trying to multithread something and ran across this:
http://learn-powershell.net/2015/03/31/introducing-poshrsjob-as-an-alternative-to-powershell-jobs/
Attempting to use but getting errors and not able to access the data I need. Let me explain. I have an extremely simple example here:
#('12.34.56.78')|Start-RSJob -Name {"TEST_$($_)"} -ScriptBlock {
Param($Computername)
Test-Connection -ComputerName $Computername -Quiet
}
get-RSJob|Receive-RSJob
This actually errors saying computername is null. Any type of command I place in here same error comes up saying computername is null. How to get rid of this and how to access the Boolean value that should be returned.
This returns a true or false on the command line but I cannot access this value when run in this script.
Eventually this will need to take an array of IP's and I will need to access all values returned for each machine. I don't have to use this posh module but need threads and thought this a good choice. Any advice here is appreciated.
It looks like you found a bug in my module with using Param() to host the incoming data in the pipeline. Fortunately, you can work around this by just using $_ in the scriptblock.
#('12.34.56.78')|Start-RSJob -Name {"TEST_$($_)"} -ScriptBlock {
Test-Connection -ComputerName $_ -Quiet
}
get-RSJob|Receive-RSJob
That being said, I definitely need to stomp that bug.
Edit: The issue with returning a $False is a bug ($True returns fine) in Receive-RSJob. I'll fix that as well.
I need to retrieve the details of all deployed SharePoint solutions, as are displayed in the Central Administration > Operations > Solution Management (AKA the Solution Store), using a PowerShell script (v2.0). Can anyone offer any guidance on how to retrieve this information from the SharePoint solution store via the SharePoint API?
Thanks, MagicAndi.
This is actually pretty easy to do. You conect to the SP Farm and just request get_Solutions.
Here is an example:
# Connect to the Farm
$SPfarm = [Microsoft.SharePoint.Administration.SPFarm]::get_Local()
# What Solution are we looking for?
$solution = "sharepointlearningkit.wsp";
# Get the solutions
$currentSolution = $SPfarm.get_Solutions() | Where-Object { $_.DisplayName -eq $solution; }
$currentSolution;
Based on Mitchell's answer, I have used:
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
function Get-LocalSPFarm()
{
return [Microsoft.SharePoint.Administration.SPFarm]::Local
}
function List-Solutions()
{
$farm = Get-LocalSPFarm
foreach ($solution in $farm.Solutions)
{
Write-Host($solution.DisplayName)
# Get-Member -InputObject $solution -MemberType property
}
}
All credit to Mitchell!
You can call stsadm.exe -o enumsolutions from your powershell script. It returns XML data which you can easily convert to [xml] data type and see whatever you need from that.
(stsadm lives in c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin)
The output consists of statements similar to this
<Solution Name="yoursolution.wsp">
<Id>ab693dcd-6483-45ad-abba-9c996c67b6e0</Id>
<File>yoursolution.wsp</File>
<Deployed>TRUE</Deployed>
<WebApplicationSpecific>TRUE</WebApplicationSpecific>
<ContainsGlobalAssembly>TRUE</ContainsGlobalAssembly>
<ContainsCodeAccessSecurityPolicy>FALSE</ContainsCodeAccessSecurityPolicy>
<Deployment WebApplication="http://devserver/" />
<LastOperationResult>DeploymentSucceeded</LastOperationResult>
<LastOperationTime>10/26/2009 9:06 AM</LastOperationTime>
</Solution>
Here are three powershell cmdlets I use to pull back the solution information. Mine are simple compared to the ones above but I thought I would submit them anyway :)
In SP2010 Management Shell
To list all the solutions. Returns solution name, id and deployed status
Get-spsolutions
To list all the properties of a particular solution
get-spsolution -identity | select *
List all solutions, properties and output to a file to read :)
get-spsolution | select * | out-file c:\solutions.txt
I've long had a bunch of VBS automations for IIS 6, including one that gets/sets complex server bindings on several farms of paired servers, each having dozens of apps, each app having 3-12 host headers. Each app has hostname, hostname-fullyqualified, and Disaster Recovery enabled hostname, so they can be a mess to maintain manually.
I did all my vbs stuff using ADSI, but I'm thinking WMI is probably more flexible than ADSI from a full server maintenance perspective. Please correct me if I'm wrong. So now I'm trying to move up to PowerShell + WMI to prepare for Windows 2008 + IIS 7.5. I'm enjoying the learning process, but I've hit a roadblock on this problem.
I can get/set all properties via WMI on my IIS 6 web servers, except ServerBindings. I feel like I'm close, but I'm missing some layer of containment, and I just can't get the objects I'm building to cast over to the right automation object.
The following code gets and reads the ServerBindings just fine. I simply can't figure out a way to write my changes back. Any advice is welcomed.
$objWMI = [WmiSearcher] "Select * From IISWebServerSetting"
$objWMI.Scope.Path = "\\" + $server + "\root\microsoftiisv2"
$objWMI.Scope.Options.Authentication = 6
$sites = $objWMI.Get()
foreach ($site in $sites)
{
$bindings = $site.psbase.properties | ? {$_.Name -contains "ServerBindings"}
foreach ($pair in $bindings.Value.GetEnumerator())
{
# The pair object is a single binding and contains the correct data
$pair
$pair.IP
$pair.Port
$pair.Hostname
# And this line will successfully erase the contents of
# the ServerBindings
$bindings.Value = #{}
# but I can't figure out what to do to update $bindings.Value
}
$site.Put()
}
I'm liking Powershell so far, so thanks for any help you're able to offer.
Alright. I got distracted with major disk failures. The fun never stops.
Anyway, the solution to this problem is simpler than I'd made it:
process
{
$bindings = $_.ServerBindings
foreach ($binding in $bindings)
{
$binding.IP = $ip
$binding.Port = $port
$binding.Hostname = $hostname
}
$_.ServerBindings = $bindings
$_.Put()
}
ServerBindings is an array, but it likes to be an array of its own kind. I was trying to build the array from scratch, but my home-rolled array didn't smell right to Powershell. So, pull the array out of ServerBindings into a new variable, manipulate the variable, then assign the manipulated variable back to the ServerBindings property. That keeps all the right typing in place. It's smooth as silk, and seems easier than ADSI.