The first script will report on all of the custom 404 pages (MOSS Web Application – FileNotFoundPage property).

Get-Custom404.ps1

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
$service = $farm.services | Where-Object {$_.TypeName –eq "Windows SharePoint Services Web Application"}
$service.WebApplications | Select-Object DisplayName, FileNotFoundPage

The script is designed to be run on one of your Web Front End servers and attach to the Local SharePoint farm. The third line returns only the Web Service that contains your Web Applications for the SharePoint farm. Finally, the last line parses each Web Application in your farm and returns the Display Name and the value of the FileNotFoundPage property.

This script can also be modified to select only items that DO or DO NOT have a FileNotFoundPage property populated. To make this change, simply modify the last line as so:

$service.WebApplications | Where-Object {$_.FileNotFoundPage –eq $NULL} | Select-Object DisplayName,FileNotFoundPage

(Those applications that do NOT have a Custom 404 page.)

OR

$service.WebApplications | Where-Object {$_.FileNotFoundPage –ne $NULL} | Select-Object DisplayName,FileNotFoundPage

(Those applications that DO have a Custom 404 page.)

If you have not populated this field at some point in the past, then you will not have anything listed in the FileNotFoundPage column.

However, if you would like to add a Custom 404 page to your site(s), the following script may come in handy.

Set-Custom404.ps1

Param([string]$WebApp,[string]$custom404file)
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[system.uri]$uri = $WebApp
$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($uri)
$webapp.FileNotFoundPage = $custom404file<br/>$webapp.Update()

The Set-Custom404 script must be run as a Farm Administrator or at a level that can modify the database. This script does not return any status unless there is an error with the update.

In this post, I will discuss how to use Powershell to extract information in the ULS logs that correlate to items in the Windows event logs. I won’t say that this is a silver bullet to find any problem you might be having and fix it, but I believe this can show some really useful information in trying to troubleshoot the problem.

The first thing we need to do is to to load the SharePoint assembly into memory.

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

Now that we have the assembly loaded, we can access the SPDiagnosticsService class to find out where the ULS logs are stored. By doing this, the script becomes more portable and SharePoint tells the script where to look for the files that we will search.

$diagSvc = [Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local

You must be a Farm Administrator to be able to access this object. The “LogLocation” property contains the location of the log files on the file system.

$ULSLogsLocation = $diagSvc.LogLocation

The script can be modified to look for other time frames, but for purposes of this article, I will look into the event log for the past six hours. Depending on the configuration of your farm, the logs may be truncated to a much smaller time frame. If your farm is configured to keep a small number of ULS logs, then you will need to be vigilant to use this script as quickly as possible so as not to lose the log files. To set the start date, we will use the Get-Date cmdlet and then subtract six hours. We will also be using a WMI query to search the Windows Event Logs. The WMI queries require time to be in Coordinated Universal Time (UTC) format (YYYYMMDDHHMMSS.ffffff+off). If you are not familiar with this format, you can see this article on Wikipedia to learn more. To make things easier, we will use the System.Management.ManagementDateTimeConverter class to set the strings up properly.

$startDate = [System.Management.ManagementDateTimeConverter]::ToDmtfDateTime((Get-Date).AddHours(-6))

Let’s break this down a bit. If the Get-Date cmdlet returns “Wednesday September 1, 2010 10:30:00 PM,” then we will subtract six hours, which will give us a result of “Wednesday September 1, 2010 4:30:00 PM.” The ToDmtfDateTime method will convert that date string into 20100901623000.000000-240. The resulting string is based on a machine that is set for the Eastern Daylight Time zone (-240). WMI queries understand this date format.

Now that we have our start date, we can begin assembly of the WMI query. If you are familiar with SQL queries, this should not be difficult to understand.

$wmiQuery = "SELECT TimeWritten FROM Win32_NTLogEvent WHERE LogFile='Application' AND Type='Error' AND TimeWritten>'$($startDate)'"

The query will return only the timestamp for any Error messages in the Application Event Log in the prior six hours. Now we can use this query to get some results.

$errorTimes = get-wmiobject –query $wmiQuery

If you have seen errors in the event logs during the past 6 hours, you should now have some objects in the $errorTimes variable. I caused some errors earlier and have some errors to report…

Now, we can use these times to isolate certain entries in the ULS logs. But first, we will need to turn these UTC times back into normal times. There are a couple of ways that this can be done, but I am going to translate these back into user-friendly times before we start searching the ULS logs.

$searchTimes = $errorTimes |Select TimeWritten | get-unique –asString | Foreach-object {[System.Management.ManagementDateTimeConverter]::ToDateTime($_.TimeWritten)}

Here we are piping each time entry in the $errorTimes variable and parsing each one. We then take each TimeWritten property, select only the unique items, and run it through the ToDateTime method to get back to a date/time string that we can understand.

We are almost ready to search the files for the information we are looking for. In order to find the specific files we need, we have to use the correct Culture setting. In my servers, the culture is set to “en-us.” To be able to capture the dates in the proper format, we will need to set a variable to carry this information.

$culture = new-object System.Globalization.CultureInfo("en-us")

You will see this new $culture variable used in the next code block when we designate the proper date and time formats that we will use to search. This block does the heavy lifting. (Don’t worry! We will put it all together in one concise script at the end.)  Also notice in this block the “Write-Host” entries.  By outputting this information to the screen, we can let the user know that something is happening as it goes through each file.

$ulsEntries = $searchTimes | Foreach-object {
    Write-Host "Searching for error stamped: $_" –foreground Yellow
    $logDate=$_.ToString("MM/dd/yyyy", $culture)
    $fileDate=$_.ToString("yyyyMMdd", $culture)
    $fileTime=$_.ToString("HH", $culture)
    $time=$_.ToString("HH:mm:ss", $culture)
    Get-ChildItem $ULSlogLocation –filter "$computerName-$fileDate-$fileTime*.log" | select –expand FullName | Foreach-object {
        Write-Host "Reading from: $_"
        Get-content $_ | select-string $logDate | select-string $time | Foreach-object {$_.Line}
    }
}

Let’s break this section down.

1. We take the items in the $searchTimes variable and cycle through each one ($searchTimes | Foreach-object {).
2. Next, the script writes out the time stamp that is being searched for (Write-Host “Searching…). The “-foreground Yellow” argument turns the text color yellow for easy tracking.
3. The next four lines store our dates and times in different formats to be used in the next few lines. Notice that we use the $culture variable that we instantiated earlier to get the right formatting on the date and time strings.
4. The Get-ChildItem cmdlet looks in the directory specified in the $ULSLogLocation variable. It only searches for files that start with the $computerName and has the $fileDate and $fileTime in the name and ends with “.log”. So, in the test environment, the computer name is “MOSS” and assuming we are looking at one of the dates in the screenshot above, we would look for a file that looks like, “MOSS-20100901-09xx.log.” Since we don’t know what interval the Sharepoint servers are using, the “xx” can be what “minute” the log file was started. This keeps the number of files we search through at a minimum.
5. The file object information gathered by the Get-ChildItem command gets piped over to the select-object cmdlet which filters out only the FullName property and expands it so that we return only the value to the next pipe. Now we cycle through each filename and output which file we are reading. This lets the user know that something is happening.
6. Now that we are looping through each filename, we will “get-content” from each file and run each line through a couple of filters. The first filter looks for any line with the $logDate (remember we formatted this differently than the $fileDate) and, if it matches, will look for any of those lines with the $time that matches. Any of these lines that match both criteria are then output to the console.

For each error that you extract from the Event Logs, you could have one or more entries in the ULS logs. Each of these entries will be time-stamped to match what was in the event logs, so you can match them back up to the event log errors. Looking at this image…

You can see the times are matching up to what I have in the earlier screenshot. I just output the information to a text file so I could open and review it in notepad. Unfortunately, I don’t have space to show the entire line on this screen.

In this example, I have shown how you can match up error entries to ULS log entries. You can modify the WMI query to also look for warnings or any specific error messages by modifying the SELECT statement and telling it what to return. For instance, if you wanted to match up any ULS log entries that match Event ID 1309, then you could change the query to read:

"SELECT TimeWritten FROM Win32_NTLogEvent WHERE LogFile='Application' AND EventCode='1309'"

You can also change the time frame that the event logs are searched. In this example, I used six hours. You may only need one hour. Any of these settings can be changed to suit your needs. I can tell you that six hours of ULS log files can take a bit of time to search. At least with this, you can start the script and then go get some coffee or lunch…or work on something else..yeah, that’s it.

As I was writing this script, I was trying to find a more efficient way of gathering specific entries in the ULS logs based on errors received in the Event Logs. I hope that this will help you to be more efficient in your work as well.

As promised, here is the complete source code for the snippets listed above:

[void"][system.reflection.assembly]::LoadWithPartialName("Microsoft.Sharepoint")
$diagSvc = [Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local
$culture = new-object System.Globalization.CultureInfo("en-us")
$computerName = get-content env:Computername
$ULSLogLocation = $diagSvc.LogLocation
$startDate = [System.Management.ManagementDateTimeConverter]::ToDmtfDateTime((Get-Date).AddHours(-6))
$wmiQuery = "SELECT TimeWritten FROM Win32_NTLogEvent WHERE LogFile='Application' AND Type='Error' AND TimeWritten>'$($startDate)'"
$errorTimes = get-wmiobject -query $wmiQuery
$searchTimes = $errorTimes | select-object TimeWritten | get-unique -asString | foreach-object{[System.Management.ManagementDateTimeConverter]::ToDateTime($_.TimeWritten)}
$ulsEntries = $searchTimes | foreach-object{
 Write-Host "Searching for error stamped: $_" -foreground yellow
 $logDate=$_.ToString("MM/dd/yyyy", $culture)
 $fileDate=$_.ToString("yyyMMdd", $culture)
 $fileTime=$_.ToSTring("HH", $culture)
 $time=$_.ToString("HH:mm:ss", $culture)
 get-childitem $ULSlogLocation -filter "$computerName-$fileDate-$fileTime*.log" | select-object -expand FullName | %{
  Write-Host "Reading from: $_"
  get-content $_ | select-string $logDate | select-string $time | %{$_.Line}
  }
 }
$ulsEntries | out-file "$($computerName)_ULS.txt"

Ok, so after my last post, I decided to become proactive and update my farm to the latest cumulative update (June, 2010 at this time). Everything went pretty smooth until I began the PSCONFIG phase of the installation. From that point, everything started going downhill. I had errors stating that stored procedures were not able to be found and that expected valued for other functions were not supplied. I even tried to delete all the databases and websites from both of my servers and re-run the Sharepoint Products and Technologies Wizard to start over. Even that did not help the problem as I still got errors stating that the stored procedures failed. Oh well.

So, I have decided that now is a good time to rebuild the environment and to try something new. I am going to uninstall Sharepoint from both servers and re-install the platform. However, I am going to attempt to do so with slipstreamed media. Slipstreaming updates has been available for Windows Server technologies for a while, and, if kept up-to-date, makes re-installation much faster since you don’t have to download the plethora of updates that show up on Automatic Updates after a new installation. In my reading, it seems that slipstreaming updates for Sharepoint are a bit easier. We shall see. Please note, that if you are going to install MOSS on a Windows 2008 server, you must use this procedure to bring the binaries up to service pack 2.

Here is the procedure that I used:

1. Create your distribution source (C:\images\mossbuild\dist). This is the directory that I am using to build the slipstreamed version.
   

    

2. Download the updates that you want to slipstream. For this exercise, I am slipstreaming Service Pack 2 and the June 2010 Cumulative Update (CU).

The Cumulative Updates will have to be requested from Microsoft. The will send you an e-mail with a link to download the files. I have put all four files in a sister directory (C:\images\mossbuild\updates).

1. Extract all four files using the following commands. I am extracting these files to a subdirectory of the updates folder.
   *    officeserver2007sp2-kb953334-x86-fullfile-en-us.exe /extract:c:\images\mossbuild\updates\MOSS_SP2 /quiet
   *    wssv3sp2-kb953338-x86-fullfile-en-us.exe /extract:c:\images\mossbuild\updates\WSS_SP2 /quiet
   *    office-kb983310-fullfile-x86-glb.exe /extract:c:\images\mossbuild\updates\SP_June_2010_Rollup /quiet
   *    wss-kb983311-fullfile-x86-glb.exe /extract:c:\images\mossbuild\updates\WSS_June_2010_Rollup /quiet
2. Now I have a folder with four zip files and four extracted folders.
   
3. From here, open up each folder and you should find a list of .MSP files. These are the files you want. Copy all of the .MSP files from each of these folders to the mossbuild\dist\updates folder (c:\images\mossbuild\updates).
   
   This image is of one of the update folders. Not all files are displayed here.
4. Your \dist\updates folder should now be filled with a bunch of .MSP files and a couple of .TXT files. Everything that is in the “dist” folder is your installation media for the new Sharepoint installation. You can take this and move it to a network location or burn it to a DVD for use. I have created a new zip file with the installation media and copied it to the server MOSS for installation. I am using e:\install for the location to place the installation files on the server. NOTE: If you are building this package for x64 architecture machines, you will need to verify that you have two different install sources and have downloaded the correct update versions to slipstream.
5. So, now to begin the installation process…
   
   All of my options have been set and the install key has been entered.The updates that we copied in are now being applied as the installation continues…
   
   This takes a really long time to complete, so be patient.
6. Once the installation is completed, you can begin the farm connection process. In this case, since I hosed my original farm, I need to create a new farm.
   

   Enter the specifics for the new farm…
   

   Settings to your liking…
   

   Verify that all is well…
   

   And off you go!
   

7. Server is installed with the correct version number.
   

When I first started this process, I ran into some rather interesting problems. I ended up running this process several times trying to figure out what was wrong. As it turns out, it seems that I had downloaded the WSS with SP2 installation and thought I had just downloaded the updates. If you do this, and extract the files to the update folder, the SP2 updates are buried deeper in another Updates folder and is never seen by the installation binaries. Therefore, the Add/Remove Programs version shows that the binaries are updated, but the WSS files are not updated and the database schema does not update.

At any rate, I now have a solution that I can use going forward to (fairly) quickly restore a new Sharepoint farm.

As I began, I remember the words of an instructor saying to always choose the “Full Install” option on Sharepoint so that you always have the option to add more servers for scalability. So, following suit, I built up a Windows 2003 image with all the security hotfix and service pack trimmings. I started the MOSS 2007 installation and completed that without any problems. The next problem I found was to make sure that both servers had the same binaries installed. I knew that some patches were installed on the original machine, but I had not installed Service Pack 2. I felt like now was a good time to do that. So, I queued up all the updates on MOSS2 as they had been on MOSS and then also added the Windows Sharepoint Services and Sharepoint Server Service Pack 2 files. I also queued the SP2 files on the MOSS server as well.

I had no problems installing all of the patches on the MOSS2 server, but I did hit a small snag on the MOSS server. It seems that there is a feature that needs to be activated in order for the SP2 files to install. Thanks to a post from Mattias Karlsson, a colleague of mine, I found this post about how to activate this feature and the details behind the problem. Once the feature was activated on server MOSS, the installation of the service pack completed without any problems.

Now comes the fun part in this situation. As I completed the PSCONFIG section on server MOSS, I needed to connect MOSS2 to the farm. When I began, everything looked normal. I chose to join an existing Sharepoint farm.

The wizard was able to successfully connect to the SQL database and find the Configuration Database for the farm.

The problem came in step 2, where it indicated a problem…

I spent some time looking at other posts about this problem trying to figure it out. A lot of the posts indicated that there might be a mismatch in the binaries. I went back and verified the file versions on the system to see that they were the same, and they were. The event logs were even more misleading as they indicated that the database could not be found.

The SQL exception above was incredibly confusing because I was able to use SQL Management Studio using the SQL user account to be able to see the database and read the tables. As I continued reading, I found a post that mentioned the SQL Surface Area Configuration. I knew that I had gone through the SQL Server Configuration Manager to grant access to the port and address and that it was enabled for listening. So, I double-checked the Surface Area Configuration. As I thought, the server was enabled for TCP/IP communication to the service.

What I also found was that the SQL Browser service was disabled. Once I started the SQL Browser Service,

everything clicked into place and my server is now connected to the Sharepoint farm.

Unfortunately, there are no prizes for reading, commenting, or re-posting my entries.  However, I hope that things that I learn and write about here will be helpful for others.

I decided to start this blog to document my findings and learnings about SharePoint operations and administration.  While my articles may not display the most efficient way of performing a task in SharePoint, I am open to suggestions to better what I do in the field.