My PowerShell ISE WishList
This will probably be a Part I of several. As the SharePoint community becomes more versed in PowerShell, the more folks are going to demand of it, and the ISE (Integrated Scripting Environment). Here are some features I wish Microsoft had incorporated into the PowerShell ISE.
1. Find in Files (from Visual Studio)
2. Projects (from SSMS, SQL Server Management Studio)
Diagnostic Logging, Part III – SharePoint Trace Logs: There’s a script for that
In Part III of my Diagnostic Logging series, we’ll have a look at the PowerShell command, Get-SPLogEvent.
No matter what you want to do with your trace logs, there’s a script for it. Well, you may have to write it, but there is one! Here are some examples you can copy and paste to get you started. Once you get the hang of it, it’s really easy to figure out.
### Get all events within the last 10 minutes
get-SPLogEvent -StartTime (get-date).AddMinutes(-10)
### Get all HIGH level events of the last 10 minutes
get-SPLogEvent -StartTime (get-date).AddMinutes(-10) | ?{$_.level -eq “high”}
### Get all High level events, selecting just the first 25 items and their
### correlation id and category, and sorting it by category
get-SPLogEvent -StartTime (get-date).AddMinutes(-10) | ?{$_.level -eq “high”} | select correlation, category -first 25 | sort category
### Want to see what’s up with your timer jobs in the last half hour
get-SPLogEvent -StartTime (get-date).AddMinutes(-30) -minimumlevel “Medium” | ?{$_.Category -eq “Timer”}
Here are some screen grabs so you can see a little of what the output is like.
#1. Get the log entries from the past minute that are High level. The | means pipe, or “send the output to.” In this case, we’re sending the output to a Where-Object clause ( that’s the ? ). This takes each result and filters it in or out of the result set.
2. Same thing as #1, only use 10 minutes, then sort the output. The | means pipe, or “send the output to.” In this case, we’re sending output to another powershell command, called sort.
3. Here is the same command from #2, but we now have a select clause. Just like in SQL, this clause isspecifying what fields to display.
4. This is the same as #3, except we’re also specifying that we want only the first 25 results. Then, we’re taking one of the correlation tokens and specifying results that contain that exact correlation token.
Hopefully this is enough to get the exact result sets you’re looking for. If not, leave me a comment and I’ll try to get you the script you need.
PowerShell error: The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.
On my development VM, I created a new user in AD. I added the user to my Farm Admins. But when I loaded powershell, I got the message
The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.
As it turns out, I hadn’t yet given my account any rights to SQL. Things began to work once the account had access to the WSS_Content db. Check your access by SQL Management Studio, under WSS_Content, Security, UserName > Right Click > Properties. I started a new PS window, too, just in case.
Move over STSADM, SharePoint has a new girlfriend: PowerShell
In 2007, we really enjoyed spending time with stsadm. She was like a girlfriend. Now that we are in 2010, we have a new girlfriend: PowerShell. I guess that leaves stsadm as a jealous girlfriend-past.
Turn on the Developer Dashboard via PowerShell
I found some outdated information for the SharePoint snap-in for PowerShell. The cmdlet to enable and disable the developer dashboard has been deprecated. To use powershell, we ultimately need to use the Object Model.
To view the answer, just scroll to the bottom!
In particular, we’ll use this Library::Object
[Microsoft.SharePoint.Administration.SPWebService]::
ContentService.DeveloperDashboardSettings; The original documentation said to use this:
PS C:\Users\svc_sp_admin> Set-SPFarm -DeveloperDashboardEnabled
The term 'Set-SPFarm' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:11 + Set-SPFarm <<<< -DeveloperDashboardEnabled + CategoryInfo : ObjectNotFound: (Set-SPFarm:String) [], CommandN otFoundException + FullyQualifiedErrorId : CommandNotFoundException
So I tried this:
PS C:\Users\svc_sp_admin> Set-SPFarmConfig -DeveloperDashboardEnabled Set-SPFarmConfig : A parameter cannot be found that matches parameter name 'DeveloperDashboardEnabled'. At line:1 char:44 + Set-SPFarmConfig -DeveloperDashboardEnabled <<<< + CategoryInfo : InvalidArgument: (:) [Set-SPFarmConfig], ParameterBindingException + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.SharePoint.PowerShell.SPCmdletSetFarmConfig
Finally, I was told by a certain ADMIN to use the OBJECT MODEL. LOL. He was right, though. 🙂 He’s a good admin and developer wannabe.
PS C:\Users\svc_sp_admin>
[Microsoft.SharePoint.Administration.SPWebService]::
ContentService.DeveloperDashboardSettings;
DisplayLevel : Off
TraceEnabled : False
RequiredPermissions : AddAndCustomizePages
MaximumSQLQueriesToTrack : 50
MaximumCriticalEventsToTrack : 50
AdditionalEventsToTrack : {}
Name :
TypeName : Microsoft.SharePoint.Administration.SPDeveloperD
ashboardSettings
DisplayName :
Id : d72a704a-81a1-429f-8c4d-5372e5524b42
Status : Online
Parent : SPWebService
Version : -1
Properties : {}
Farm : SPFarm
UpgradedPersistedProperties :
And while I appreciate the blogs out there that teach Admins how to code, let’s face it, even developers don’t instanciate objects when they don’t need them. So, here’s the long way that some suggest:
$val = "On";
$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
$cs.DeveloperDashboardSettings.DisplayLevel = ([Enum]::Parse([Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], $val));
Write-Host ("Developer Dashboard Level: " + $cs.DeveloperDashboardSettings.DisplayLevel)
Let’s consolidate that:
$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
$cs.DeveloperDashboardSettings.DisplayLevel = ([Enum]::Parse([Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], “On”));
Write-Host ("Developer Dashboard Level: " + $cs.DeveloperDashboardSettings.DisplayLevel)
OK. One more consolidation. Use this single command to set the developer dashboard.
[Microsoft.SharePoint.Administration.SPWebService]:: ContentService.DeveloperDashboardSettings.DisplayLevel = ([Enum]:: Parse([Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], “On”));
It’s very long, so I suggest copy and paste. I had to include RETURN breaks as it scrolled off the page.
And to view it, use
[Microsoft.SharePoint.Administration.SPWebService]:: ContentService.DeveloperDashboardSettings
Happy SharePointing!
David Frette's Blog 
