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.

Diagnostic Logging, Part II

Diagnostic Logging Part II
Overview of how the WSS_Logging database works

So let’s consider the Unified Logging System in SharePoint 2010. All trace logs, event logs, and usage logs get thrown into SQL. This is really awesome. Not only do we have a central place to hunt down errors, but we can report on it!  On each local server, we can use the PowerShell commands to scan thru the logs. I’ll talk about that more in Part III. However, the real power isn’t in PowerShell. PowerShell cannot (well, does not) scan other servers in your farm. It doesn’t access the SQL data, either. It does read the logs on the local server.

But imagine if you have a user who gets an error and is provided a correlation token. What will you do with that? Will you run a PS command on each server in your farm until you strike gold? Well, you would have to if you don’t have ULS configured. It won’t be long and you’ll be sure to have it turned on. Once it’s on, you can have a custom ASPX page or even a WPF application go get you some data!

First, stroll on over to your Central Admin web app. Click on configure usage and health data collection. The key is collection.  I’m going to turn on everything and configure my schedules.

Now I pop open one of my favorite tools, SQL Management Studio. With it, I go into my DB and take a look at the tables and views.

Notice all the partitions for ExportUsage. Well, there are also partitions for all other tables, too. I just didn’t get a screen grab of them. It appears there are 31 partitions for each table. Just a hunch here: 1 for each day?!

And now take a look at the views.

Let’s right click one and select design. Don’t worry about the error. It’s just telling you as you ‘design’ this query, it won’t be graphic.

Not surprisingly, it’s a UNION ALL of each partition.

But wait!! Where did that ULSTraceLog view come from.

Here are the views again:

I actually had to go back into Central Admin and turn on Web Analytics. Oddly enough, WA is what collects the trace logs.

Diagnostic Logging, Part I – The basics of diagnostic logging in SharePoint 2010

Diagnostic Logging, Part I

I just had to set some diagnostic logging in SP 2007 today. Ugh, what a pain. There is no long list to show me all the current values. There is no easy way to see what is a default value and what is custom. And there is no easy way to set it back. Thankfully SharePoint 2010 is much easier. Before I dig in deep, I just wanted to do a “basics” post first.

The basics of diagnostic logging. 

These three screens show the event throttling.

 Notice that I’ve set the Secure Store to verbose. Since that is not the default, it is bolded.

 Instead of needed to know what it was before, you can just Reset to default.

And since all properties with Secure Store Service are defaults, the grouping is no longer bolded.

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.

God Mode on Windows 7, Windows 2008

Sometimes hunting thru the Control Panel is a pain. When will we be able to create custom views? Probably not anytime soon. So, let’s look at one way to display a large list of Control Panel items. It’s called God Mode.

Find a place you would commonly use, such as Desktop, C:\, or even a new toolbar on the taskbar. In it, create a new folder and give it the God Mode string:
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Here is a God Mode window with a view

Here is where I put God Mode on my machine. It’s on a taskbar toolbar.

SQL ULSTraceLog Tables and View don’t exist!

So I turned on event logging, and configured a collection schedule. But that did not turn on the data collection for my trace logs (the 14\Logs\<server>-<date>-<time>.log  files).

To get the trace logs collection, we must turn on Web Analytics.

Go into Central Administration, click Manage service applications

Select New on the ribbon (Fluent UI) and choose Web Analytics Service Application.

 

I had to use two screen shots to get the new dialog. Here it is. Configure your Application Pool and identity. Then enter your database information. Finally, configure your data retention period.

Now that you have your Web Analytics Service Application configured, you will see your ULSTraceLog tables/view in SQL Server. Now get ready for reporting!!

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!

Meeting unique validation requirements for content types in the same list

Meeting unique validation requirements for content types in the same list.
We can create seperate forms for each content type using InfoPath. It’s pretty easy. However, you cannot customize New/Edit/View forms with InfoPath. You can, however, use SPD and ListView WebPart. That will be the topic for another post.

So, first I’ve set up my Tasks list to have an extra content type (ignore the summary task – I will). I have the Task content type, which is out-of-the-box. I also have a Simple Task content type, which has Task as the parent. I’ve added a new field, called Owner. That’s the only difference. See List Settings from within IE and then from within SPD.

(sorry for the poor image, WordPress is giving me a headache with it. SimpleTask has an Owner field, Task does not.)

Now go to your Tasks List and click Design Forms in InfoPath. Select the content type you wish to modify. I’ll demo a custom InfoPath form for my SimpleTask content type.

Here are my changes to the form (I’ve added a blue title and made the Owner field red to bring attention to it):

Using the InfoPath client Backstage area, found under File tab, the form is published to the list.

This message indicates all went well.

Now, in the web browser, selecting a new SimpleTask from the New Item menu will display the newly customized form.

Here is the customized Simple Task content type form.

A customized Task form can also be created.

Here is the customized Task content type form.

Now let’s make the Task more complicated in validation. Let’s create a rule that says the “Due Date” is required when a “Start Date” is provided.

After publishing the Task form and starting to fill out a new task item, the validation error is revealed.

So, in summary, you can have an InfoPath-customized form for each content type. This works well if you need to validate data differently for each content type. Using InfoPath, we can set our own data validation rules. Since each content type can have its own form, each content type can have its own validation rules.

Quick Reminder – Don’t install ALL of Visual Studio

Quick Reminder: When installing Visual Studio, be sure to select Custom install and then remove C++. You won’t be needing it for SharePoint development.

And on your VMs, you can remove SQL Server Express. It won’t install if you have already have SQL server. But if you don’t uncheck it, you’ll get an error at the end of setup, and we don’t want to see errors at the end.

 

Removing the two unneeded items shows we’ll really only need 4.5 GB of disk space.