Home - From The Field

11/2/2009

Does this SQL Server Host a SharePoint Farm ?

I recently responded to a thread on Twitter (http://www.twitter.com) offering to describe a method of detecting whether a SQL server hosts a SharePoint farm. Several folks followed up asking for a blog on how to do this so here goes. Note: This is the same for 2007 and for 2010

Consider the way PSConfig identifies a Configuration Database when you try to join a server to an existing farm.

Once you choose to join an existing farm, you will then be asked to specify a database server. At that point you have the option of retrieving the database names of every configuration database on that server so that you can choose the farm you would like to join.

The database name field is populated by issuing the following SQL command from the WFE to the SQL Server:

SELECT name FROM sysdatabases WHERE has_dbaccess (name) = 1

The server responds with a list of all databases to which the logged in user has access.

In order to determine which databases are configuration databases, the following SQL query is used:

SELECT @Version=Version FROM [dbo].[Versions] WHERE VersionId=@VersionId

In this case the VersionId that SharePoint is trying to match is:

60B1F2BE-5130-45AB-AF1D-EDD34E626B5D

Only a configuration database will have a row that matches this GUID although you will find a Versions table in all SharePoint databases.
Once the information requested is provided, clicking Next will perform the following actions.
The database id is determined using the friendly name for the database.

SELECT @dbid = db_id(@databaseName)

Next, SharePoint will read in the application settings that are related to the farm to be connected to. Once that is complete, the configuration wizard will display a final confirmation before performing the configuration.

Posted at 4:06 PM by Neil 'The Doc' Hodgkinson | Category: Administration; SharePoint 2010; Troubleshooting | Permalink | Email this Post | Comments (3)

10/29/2009

SharePoint Content Deployment Wizard to the rescue

I’ve been assisting a customer migrate some sites from a pilot MOSS 2007 farm to their production farm, the plan was to use stsadm export/import to move a handful of sites across. The export of the sites worked fine, the problems started when we tried to import them into production.

When attempting to import each of the sites the following error was received – Fatal error " Allowautomaticaspxpageindexing attribute is not declared" it turned out that they had kept their pilot environment up to date and it was running SP2 J the problem was that their production environment was still running SP1 L. It’s not recommended to use stsadm export/import between farms that are at different build levels. The simple solution would be to upgrade production to SP2 and retry the import, unfortunately this wasn’t an option. It was also critical that the content was migrated. After much scratching my head and coming up with a totally un-supported solution of hacking the export CMP file (which is basically just a CAB file) I had to find a realistic approach to migrate the content that wouldn't get me in trouble!

I then thought that I’d give SharePoint Content Deployment Wizard (SPCDW) a whirl - http://www.codeplex.com/SPDeploymentWizard. Although it’s possible to migrate entire sites using this, as it uses the same method as export/import to migrate content (PRIME API) this wasn’t an option as it would generate the same errors. The approach that I took was to use the tool to export each of the lists from the sites that needed to be migrated – these were primarily Wiki Page libraries and then imported them into production and it worked like a dream. The only issue is that things such as web part pages and the customised quick launch that they had were not brought across, the effort involved in re-creating these far outweighed the pain in having the sites on a pilot system that was starting to creak!

The process that I used was as follows.

· Create a site in production with the same template as pilot

· Used SPCDW in the pilot environment to export all of the lists that contained data that needed to be migrated for a site. The tool allows you to select specific lists from the source site – cool!

· Used SPCDW in production to import all of the lists

· Repeat process for each site to be migrated

· Manually re-create customisations to the look and feel

Not an ideal approach I know but if you're desperate it’s always an option!

Posted at 10:31 AM by Brendan Griffin | Category: Restore | Permalink | Email this Post | Comments (0)

10/19/2009

Single Server Complete Install of SharePoint 2010 using local accounts

Something that was possible in SharePoint Server 2007 has become tricky in SharePoint Server 2010. The complete installation on a single server using non-domain accounts. Something most developers, demonstrators and testers do a lot of suddenly requires the use of domain accounts instead of local machine accounts. Or does it....

The recommendation for a single server build of SharePoint 2010 is to use the Stand Alone installation giving you SQL express and a default configuration. But what if you want to use SQL Server 2008 and to have more control over the build, and to use local service accounts. In this case you need to use complete install and either PowerShell alone or a combination of Windows PowerShell and PSCONFIG(UI).EXE

To begin with carry out your SharePoint 2010 installation using the advanced option and complete as the server type. This is recommended in a farm configuration.

Next you would think to use either PSCONFIG or PSCONFIGUI to create the farm. Well you would be wrong

PSCONFIG.EXE -cmd configdb -create -server neilhw2k8r2 -database sharepoint_2010_config -user neilhw2k8r2\administrator -password ******** -passphrase ********
-admincontentdatabase sharepoint2010_admincontent

Results in

The specified user neilhw2k8r2\administrator is a local account.

Local accounts should only be used in stand alone mode.

So how do we get around this limitation without using the corporate domain or else promoting the server to a domain controller.

Windows PowerShell is your friend, New-SPConfigurationDatabase allows you to specify none domain credentials for the farm.

To execute this command launch the SharePoint 2010 management shell (in the same location as the central admin link) and simply type the command at the cursor and press enter.

The beauty of the Windows PowerShell approach is you get prompted for the missing command line attributes instead of the rather horrible error dialog that PSConfig throws at you

After this completes you will find in SQL a new configuration database and an admin content database (unfortunately the GUID is back but that can be fixed if necessary)

Next the simplest way to complete the installation is revery back to PSConfigUI as you now are starting with the server already joined to the farm.

Follow the wizard through the same options as you had with SharePoint 2007 and complete the installation/configuration with the following screen

Clicking Fiinish launches the central admin website and after agreeing to report back customer experiences to Microsoft (or not) you get your first look at SharePoint 2010 central admin and the configuration wizards.

So wizard - or - manual configuration. That's a subject for another post so come back for more...

Posted at 4:36 PM by Neil 'The Doc' Hodgkinson | Category: SharePoint 2010; PowerShell; Administration; Central Administration | Permalink | Email this Post | Comments (3)

10/7/2009

Estimating Content Database Transaction Log Growth Rate - With PowerShell V2

You might argue once you’re finished reading this post that it belongs more in a SQL-focused blog rather than a SharePoint one; however it was SharePoint that brought it about, so I thought there might be other SharePoint administrators out there who will find it useful…

It all began when a customer of mine asked me for advice on measuring the rate of growth of the transaction logs of their content databases – which I found rather difficult to provide off the top of my head. Really, it is only easy and obvious if a transaction log file is configured for autogrowth and the log is never truncated, in which case you can just monitor the size of the .ldf file – but honestly, if your databases are configured this way, measurement should (and will!) be the last thing on your mind! And in any case, the customer in question had pre-sized transaction log files, with logs truncated hourly.

After some musing, we arrived at a solution involving use of the relevant SQL performance counter and a PowerShell script to parse it – thanks to the rather useful Import-Counter cmdlet available in PowerShell V2. So, here’s what we had to do:

1) On the target SQL server, set up a performance log with an instance of the 'Log File(s) Used Size (KB)' counter for each database we were interested in.

2) Run the log for an hour (could be any period of time), then copy it over to a machine running Windows 7 – only because we had one, alternatively could use any machine with the CTP of PowerShell V2 installed.

3) Run the following script, specifying the log file as the value for the input parameter:

param ([uri]$logfile = $(throw "Path to logfile not specified!"))

# Use the Import-Counter cmdlet to import perf log data into an array of data samples

# and store it in a variable

$logdata = Import-Counter $logfile.LocalPath;

# Iinitialize an empty array that will hold an object for each dynamically discovered instance

$counters = @();

# Analyze the first data sample to discover counter instances

$logdata[0].CounterSamples |

Foreach-Object `

{

if ($_.Path -ilike '*log file(s) used size (kb)')

{

# Store the discovered instance as a hastable and add it to the $counters array

$counters += @{path=$_.Path; instance = $_.InstanceName};

}

# Process all counter instances, one at a time

$counters |

Foreach-Object `

{

$counter = $_;

# Analyze each data sample

$logdata |

Foreach-Object `

{

# Filter down counter samples by matching with the name and path of the

# currently processed counter instance

$_.CounterSamples |

Where-Object {($_.Path -eq $counter.path) -and ($_.InstanceName -eq $counter.instance)}

} |

Foreach-Object `

{ # This is the Begin-Processing clause, only executed once

# Ensure the necessary variables are nullified before each sample is processed

$first = $null;

$prev = $null;

$total = $null

} `

{ # This is the Process-Object, executed for each data sample

# The following algorithm identifies the first and the last value in

# each consecutive period during which the size was on the increase

# (e.g. from immediately after a truncation to the next truncation)

# and sums up the differences between all such pairs of values

if (-not $first)

{

$first = $_.CookedValue;

}

if (-not $prev)

{

$prev = $_.CookedValue;

}

if ($_.CookedValue -lt $prev)

{

$total += ($prev - $first);

$first = $_.CookedValue;

}

$prev = $_.CookedValue;

} `

{

if ($prev -gt $first)

{

$total += ($prev - $first);

}

# Round the final result for the current counter instance

# and store it in the same hashtable

$counter.total = [math]::Round(($total / 1KB),2)

}

Write-Host

Write-Host ("Log start:`t`t`t{0}" -f $logdata[0].TimeStamp);

Write-Host ("Log end:`t`t`t{0}" -f $logdata[-1].TimeStamp);

# Calculate the duration of the logging period

$duration = ($logdata[-1].TimeStamp - $logdata[0].TimeStamp);

Write-Host ("Total duration (hh:mm:ss):`t{0:d2}:{1:d2}:{2:d2}" -f $duration.Hours, $duration.Minutes, $duration.Seconds);

Write-Host ("Number of data samples:`t`t{0}" -f $logdata.Length)

Write-Host ("Sampling interval (sec):`t{0}" -f ($logdata[-1].TimeStamp - $logdata[-2].TimeStamp).Seconds)

$counters |

select @{n="Database Name";e={$_.instance}}, @{n="Log File Growth (Mb)"; e={$_.total}} |

Sort-Object "Log File Growth (Mb)" -descending |

Format-Table –autosize

What we see in the result is this nice report, with the most heavily utilized database appearing on top:

PowerShell Window

Posted at 3:45 AM by Sergey Zelenov | Category: PowerShell; Usage Analysis | Permalink | Email this Post | Comments (0)

10/1/2009

DPM and SharePoint - Part 4 - Why do I get this error?

Now that you know how DPM works with SharePoint, it’s time to delve into the much more interesting topic of troubleshooting errors thrown by DPM. This post will focus purely on SharePoint related DPM error messages and how to troubleshoot any of these errors you may see in the UI. If you are looking for guidance on generic DPM troubleshooting, please see http://technet.microsoft.com/en-us/library/bb808913.aspx or refer to the error code catalog: http://technet.microsoft.com/en-us/library/bb795681.aspx.

Where to start?

Let’s take this error message from the DPM UI and walk through the troubleshooting steps:

DPM Error

In this case we are trying to restore the /projects sub-site to the www.contoso.com site collection. The real error message amongst all the above is “DPM was unable to import the item http://www.contoso.com/projects/ to the protected farm (ID 32005 Details: The system cannot find the file specified (0x80070002))”.

OK so now what? Not very helpful is it? It looks like we are missing a file. If you read the recommended action second there are some helpful suggestions for common failure causes including missing features and language packs. But this isn’t enough for us to resolve the problem.

At this point, you have 2 options. As a DPM administrator you may prefer to check the DPM error logs on each Web front-end server (production and recovery farm). However, as a SharePoint admin you may be more familiar with the SharePoint ULS logs on the servers. Either should give you the information you need!

The DPM Log Files

First a look at the DPM error log for SharePoint recoveries. You will need to log on to the production Web front-end that is used to protect your farm (and possibly the recovery farm server if the problem is caused there). The log file you need is located in %systemdrive%\Program Files\Microsoft Data Protection Manager\DPM and is called WssCmdletsWrapperCurr.errlog.

There are a number of log files here and yep you guessed it, SharePoint has its own which is actually quite helpful. If you think back to part 2 in this series, you will remember WssCmdletsWrapper.exe. This is the application used to connect the SharePoint Object Model (managed code) to the unmanaged DPMRA service. Therefore, the WssCmdletsWrapperCurr.errlog file is where we need to look for exceptions passed from the SharePoint Object Model to DPM!

Here are the contents of the log file for the above error:

DPM Error Log

Based on this, we can see the main exception is: “The site http://www.contoso.com/projects/ could not be found in the Web application SPWebApplication Name=ContosoPortal“... and this occurs once an SPImport has been attempted. This means the data was successfully restored from the database to the recovery farm and then copied to the live Web front-end ready for import.

The job failed because it is expecting a site at the given location. But wait, isn’t that the point, aren’t we restoring the site in the first place because it was accidentally deleted?

Yes we are! However, in the above case the /projects subsite cannot be restored because its parent site collection also no longer exists and the import process is trying to import /projects into www.contoso.com as a child object.

As SharePoint administrators we are all sighing right now (yep – remember DPM uses the content migration (PRIME) API, therefore all the same caveats apply as if you were using stsadm –o import). As DPM administrators you may be a little confused, if so and you want to learn a little more about the SharePoint containment hierarchy, I suggest you take a look at: http://technet.microsoft.com/en-us/library/cc287815.aspx and if you are feeling a little braver try http://msdn.microsoft.com/en-us/library/cc768619.aspx.

The SharePoint Log Files

I mentioned previously that it is also possible to find this information from the SharePoint ULS logs. WssCmdletsWrapper.exe will write directly into the ULS logs as it interacts with the SharePoint Object Model. Therefore, if you prefer, you can use the ULS logs to determine the error instead.

To do this, log on to the production Web front-end that is used to protect the farm and open the relevant log according to the time of the recovery failure. Search for “wsscmdletswrapper.exe” and look at each entry. For the error in this example I am given entries which correspond to those in the WssCmdletsWrapperCurr.errlog file:

SharePoint Error Log

You may also see success messages from other restores. This is perfectly normal and can be used for verification purposes if you wish.

Note the message: “ULS Init Completed (WSSCmdletsWrapper.exe, onetnative.dll)” occurs at the beginning. This shows the WSSCmdletsWrapper.exe application is hooking into the ULS logging system. You should see one of these entries at the beginning of any DPM related operations. Therefore, you can use this string to filter your search for new operations and not every line from each operation.

Common Error Causes

As you have seen above, errors may be caused purely because DPM uses the SharePoint Content Migration APIs, and because restrictions on the way objects are organised within SharePoint.

A full overview of the Content Migration APIs and what cannot be exported/imported is documented here: http://msdn.microsoft.com/en-us/library/ms453426.aspx.

Other common issues were covered in part 3, but for completeness I will include the list here too. The DPM UI may not show you the message in the format given below, so it is worth noting that whatever the error message given in the DPM UI, you can use the method shown above to retrieve the full exception message and stack trace.

· Not enough space on the recovery farm temporary storage volume. This is for the initial database restore process during item level recovery.

· A site already exists at the recovery location but uses a different template to that being restored. For example, SharePoint will not allow a site created by using a Wiki Site template to be restored onto a site created by using the Team Site template.

· A sub-site, list or item is being restored to a location without a parent Site collection. You must have a parent object in place to restore any child objects.

· The recovery farm is a different version or build of SharePoint. The build must be the same since MOSS 2007 Enterprise contains features that are not available in Standard and WSS 3.0. The farm must also be patched to the same build and have the same language packs installed.

· The recovery farm does not contain all customisations that are deployed to the production farm. If an object being recovered depends on these the recovery may fail.

Stay Up To Date

It goes without saying that all software has bugs and staying up to date with the latest patches will help ensure an error free environment. Using the above method may help when there is a suspected bug, but only a Microsoft Support Case will get you a fix!

For this reason I recommend all customers ensure they have at least Service Pack 2 for WSS 3.0 and MOSS 2007 installed on both their live farm(s) and their recovery environment. If possible, the latest SharePoint cumulative updates should also be installed. (http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx).

You should also have Service Pack 1 for DPM installed (http://technet.microsoft.com/en-gb/dpm/dd296757.aspx) and I highly recommend that you install the latest rollup package (http://support.microsoft.com/kb/970868), which includes all fixes since SP1, including many SharePoint related fixes and dependant ones to DPM and the VSS framework. I have included the SharePoint specific ones below:

· When you restore a SharePoint site that is configured to use a host header, an incorrect SharePoint site is restored.

· Data Protection Manager 2007 cannot protect the content databases if Microsoft Office SharePoint Server 2007 Service Pack 2 is configured to connect to a content database by using a SQL Server alias. Additionally, the following error is logged:

o This Windows SharePoint Services farm cannot be protected because DPM did not find any dependent databases and search indices to be protected. (ID: 32008)

· If a Microsoft Office SharePoint Server 2007 farm is configured by using a fully qualified domain name (FQDN), consistency checks or initial replication fails with error 0x80042308:VSS Object not found.

· Restoring a Windows SharePoint Services-related content database that is detached from the server farm fails with a 0x80070003 error.

· SharePoint catalog generation fails with a "The number of WaitHandles must be less than or equal to 64" message.

· The SharePoint backup process fails if DPM 2007 cannot back up a content database. If you install this update, the SharePoint backup process will finish. However, an alert will be raised if DPM 2007 cannot back up a content database.

· If a parent backup job of a SharePoint farm fails, but the child backup succeeds, the DPM 2007 service crashes.

Posted at 2:58 AM by Chris Whitehead | Category: Backup; DPM; Restore; Troubleshooting | Permalink | Email this Post | Comments (0)

9/11/2009

mergecontentdbs gotcha

Back in SharePoint 2007 Service Pack 1, a new command “stsadm –o mergecontentdbs” was released to help administrators move a site collection from one content database to another. (Despite its name it doesn’t actually merge content databases, just moves the data from one content database to another.) This was fine as long as the size of the site collection being moved was not too big.

It might take several hours to perform the whole move for a large site collection. Plus if for any reason the job crashed out during its run you could be left with orphans in either of your content databases or neither of them in working state. See http://support.microsoft.com/kb/969242/ for more information.

Recently I helped a customer upgrade their SharePoint system to SP2 with the June 09 Cumulative Update and once this was done, to move a 20Gb site collection to a new content database.

The move worked correctly and the “stsadm –o mergecontentdbs” command returned without error. Looking in the new content database I could see the data and an entry in the “sites” table which showed that this contentdb did in fact contain the moved site collection. Looking in the old contentdb at its “sites” table indeed showed that the site collection was gone.

So what was the problem?

It became clear that once the move was over, we were unable to shrink the size of the old content database. It still contained over 20Gb of data and I had no idea why it was still there.

Running a “stsadm –o databaserepair” command against the old content database showed 1000’s of orphans and upon closer inspection these where all individual sites (SPWeb objects) which had been part of the moved site collection. Running “stsadm –o databaserepair” this time again with the “-deletecorruption” switch did the job of removing the orphans after which we could shrink the old content database.

Therefore it would seem that the way the “stsadm –o mergecontentdbs” command works between SP1 and SP2 + June 09 CU seems to have changed. Indeed it seems to deliberately create orphans as part of the move.

After speaking to some of the guys on my team (hat tip to Andy D) the following blog posting came to light from the team at Microsoft who maintains the documentation you see on TechNet.

http://blogs.technet.com/tothesharepoint/archive/2009/05/21/3244169.aspx

It makes mention of the way the mergecontentdbs command was changed in the April 09 Cumulative Update and that it is now the default behaviour to leave the data in the old content database and rely on a new timer job to delete the data automatically in the background. The role of this job is to simply clean up orphans of a particular type which are generated as part of the call to mergecontentdbs.

In summary: Systems which have at least Service Pack 2 and the April 09 Cumulative Update will by default rely on a timer job to remove data from old content databases when the “stsadm –o mergecontentdbs” command is used to move a site collection from one database to another.

Posted at 3:20 AM by David Little | Category: Administration; Configuration; General; SP2; SP1; stsadm; Troubleshooting | Permalink | Email this Post | Comments (0)

9/9/2009

Create Managed Properties - The Easy Way

OK, so I got to publish another script to the SharePoint Management PowerShell scripts project - this one is called Set-ManagedProperty. Does exactly what the name suggests - allows you to automate creation of managed properties in Search configuration and mapping them onto crawled properties.

You may find this especially useful if you are planning to install Podcasting Kit for SharePoint (or have to re-build it regularly). One of the most tedious steps in the installation and configuration of PKS has always been having to create over a dozen of managed properties - now all you have to do is download and run this script, as it even defaults to properties required by PKS if given no other input!

Posted at 4:16 AM by Sergey Zelenov - MSFT | Category: Configuration; PowerShell; Search | Permalink | Email this Post | Comments (0)

7/31/2009

PowerShell Has Arrived!

This blog is long due a PowerShell section, so finally I'm starting one with this post!

I've been meaning for quite a long time to share my experiences in this area in the form of ready-to-use scripts here, but after some consideration I've decided to join the SharePoint Management PowerShell scripts project on CodePlex. So, this week I was given access and uploaded the following:

Apply-SPQuotaTemplate.ps1

Get-SPSites.ps1

Get-SiteGroups.ps1

Edit-SPGroup.ps1

Quite a few more are to be posted in the weeks to come, subject to them being double-checked and commented, so watch this space!

Posted at 8:47 AM by Sergey Zelenov - MSFT | Category: PowerShell | Permalink | Email this Post | Comments (0)

7/22/2009

SSP Admin Site Strangeness!

I recently came across a weird issue, a customer had built a farm using MOSS 2007 Standard Edition but for some reason their SSP Administration Site included links for both Excel Services and the Business Data Catalog. These shouldn’t be present with the Standard Edition as they are features of the Enterprise Edition of MOSS 2007.

The next step was to check each server within the farm to verify which version of MOSS 2007 had been installed.

The easiest way to do this is to look within the registry – HKLM\SOFTWARE\Microsoft\Office Server\12.0\

The registry key OfficeServerPremium indicates the version of MOSS 2007 installed, a 0 indicates Standard Edition and a 1 indicates Enterprise Edition.

I managed to find a server within the farm where this key was a 1; this was the culprit of the problem. The server had been mistakenly built with an Enterprise Edition key L

The next step I would recommend would be to tear down the farm and rebuild from scratch just to make sure that each and every server is Standard Edition and there are no references to the Enterprise Edition anywhere, simply removing the server(s) that have the Enterprise Edition installed doesn’t remove the links to Excel and BDC from the SSP admin site.

Now in this case we were working with a development farm that is to be rebuilt in the short term anyway so we had the ability to have a play around, we removed the Enterprise server from the farm, rebuilt as Standard and then re-added to the farm.

What I did find is that the following features are responsible for adding the BDC and Excel links to the SSP admin site(s)

· BDCAdminUILinks

· ExcelServer

By simply deactivating these features the links are removed from the SSP admin site(s). NOTE – THIS SHOULD NOT BE DONE IN A PRODUCTION ENVIRONMENT

The following commands can be used to achieve this

· stsadm -o deactivatefeature -filename bdcadminuilinks\feature.xml

· stsadm -o deactivatefeature -filename excelserver\feature.xml

In a production environment I would recommend a rebuild of the farm rather than manually removing the links by deactivating the features.

Posted at 8:53 AM by Brendan Griffin | Category: SSP; Troubleshooting | Permalink | Email this Post | Comments (0)

7/16/2009

Blocking specific traffic to your Web Servers – using Microsoft URLScan 3.1

Ever wanted to control what applications or urls get passed (or more importantly blocked by) your MOSS Web front-end Servers.

I recently came across a MOSS 2007 customer who wanted to block certain request coming from specific applications (e.g. MSIE Crawler, MS Access), The client was using Windows 2003 OS with IIS 6.0.

There are usually several ways to ‘skin-a-cat’in this case URLScan 3.1 seemed like a perfect candidate for the job, and it is a free download:

Statement on the tin:
"UrlScan 3.1 screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator. Filtering requests helps secure the server by ensuring that only valid requests are processed." http://www.iis.net/extensions/UrlScan

Note: Most of the features of URLScan 3.1 have been incorporated in IIS 7.0, so if you’re using IIS 7.0 you should be able to easily achieve the above from the GUI, see technet documentation on IIS 7.0

From the looks of it all we need to do is download and install URLScan3.1 and then add a few entries in the urlscan.ini file i.e. by identifying and denying specific user agents. (urlscan.ini file is located in the C:\Windows\System32\inetsrv\urlscan folder)

To test if this function actually worked we created the below entries in the .ini file to block Access to all ‘Mozilla’ requests; (n.b: User agent Strings can be taken from IIS log entries);

[Options]
RuleList=DenyUserAgent

[DenyHeaders]
Transfer-Encoding:

[DenyUserAgent]
DenyDataSection=AgentStrings
ScanHeaders=User-Agent

[AgentStrings]
Mozilla

These entries will need to be made on all of the servers assigned the WFE role, for testing you can just amend your Hosts file to direct you’re traffic to one specific front end, as we did.

To our delight, when we tried browsing to any sight hosted on our web server, we received the error page as described in;

Error page returned when URLScan rejects request

http://technet.microsoft.com/en-us/library/cc751375.aspx

Now that we have the format specified in the urlscan.ini all we need to do is identify which user agents we want to block and add these under [AgentStrings] (btw don’t forget to remove Mozilla otherwise no one will get through J)

To identify your Agent Strings use a combination of the entries from your IISLogs, which will look something like: Microsoft Office/11.0 (Windows NT 5.1; Microsoft Office Access 11.0.8221; Pro), (don’t forget to replace the + sign with spaces) and the list of User Agent Strings from this site: http://www.useragentstring.com/pages/useragentstring.php

We managed to successfully block the following Applications responding with unable to connect to server and unable to connect to site messages;

[AgentStrings]

;Browsers

Opera/9.64 (Windows NT 5.1; U; en) Presto/2.1.1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

;Applications

Microsoft Office/12.0 (Windows NT 5.1; Microsoft Office Access 12.0.6320; Pro)

You should also see the corresponding entries in the IIS Logs;

Success:

2009-07-15 12:49:15 10.162.74.223 GET /Rejected-By-UrlScan ~/default.aspx 80 GLOBAL\9739330 10.174.146.69 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-GB;+rv:1.9.1)+Gecko/20090624+Firefox/3.5 200 0 0 346 579 31

We blocked MS Access and got the messages unable to connect to server and unable to connect to site, as expected. You can probably modify these to redirect to something more appropriate, but these were sufficient for us.

Posted at 8:00 PM by Zaheer | Category: Administration; Authentication; IIS; Security | Permalink | Email this Post | Comments (2)

RSS Feed

1 - 10

From The Field

From The Field

11/2/2009

10/29/2009

10/19/2009

10/7/2009

10/1/2009

9/11/2009

9/9/2009

7/31/2009

7/22/2009

7/16/2009

‭(Hidden)‬ Admin Links