Since I do not like one-liner posts, I recently started writing an (ambitious?) serie of posts covering enterprise file services based on Windows Server 2008 R2 based on a presentation I gave to certain customers of mine . The first “shot” is dedicated to a new swiss-army knife-like tool from Microsoft: FSCT, standing for File Server Capacity Tool.

Until now, validating a Windows file server setup has always been a difficult task since very few tools were available on the market to adequately simulate a realistic user load. In past, tools like NetBench were considered as references. Nowadays, if you’re lucky, you can rely on your own scripting toolkit, if you’re not, you may have use Intel’s NAS Performance Toolkit, which is not bad, but farm from being “enterprise” ready. I’ve even seen some people trying to benchmark file services using SQLIO…

Architecturally speaking, FSCT is similar to other load-tests tools you would use of web application, for example: it is made of a controller, a server (the one to be benchmarked) and one or multiple clients. Optionally, you can also include an AD domain controller in the picture in order to simulate AD-based authentication. Nevertheless, FSCT is also compatible with workgroup environments, but in a degraded manner.

Note: Combining roles is a possibility but as you expect, it may negatively affect the tests. So if you’re short on machines, combine wisely and keep the other roles off the “server” role.

On the other hand, you can conduct test campaigns from more that one client simultaneously, that’s where the architectural choice is paying: up to my knowledge, no other tool can do that today.

Plan and deploy your test environment carefully…

• First, take time to read the whole paper included in the package carefully. Everything you need to know about the tool is in there
• Practise before conducting the “real” tests: since the tool is command-line based and due to the way it is distributed among systems, you may not get the result you expect from your first try (it’s not point-and-click)
• Make sure all components involved are healthy: server & clients (network configuration, drivers…, but also network components (switches and if applicable, routers or access points…). A single component improperly working may severly affect the result of the tests (argh, hard-coded duplexing/link speed)
• Copy FSCT to all systems involved (unless the server is not Windows-based) and build your own batch files to speed-up the configuration, the execution and finally the cleanup
• Unless you want to reach the limits of an HP Proliant DL 58x, do not bump the client + user count to the maximum, plan then realistically. An in any case, it is not advisable to conduct your test in production, especially, for the network in general as well as for the sanity of the AD you would populate users in...

Don’t be afraid of command-line based execution

Okay, there is no UI but who cares? Me? Yes I’ve made my own little WinForm apps to save me time (I’ll post it in the coming weeks) but frankly, once your config files and batches are ready (it take 2 hours max), command-line rules supreme over the mouse;)

And before you ask, no, there is no PowerShell support, it sounds a little old-fashion I admit

Plan multiple test scenario’s keeping in mind important factors such as:

• CIFS/SMB Version: depending on the client and server/Configuration OS version, the usage of SMB2 will greatly improve performances under virtually any circumstances. If you plan to use pre-Vista client OS or maybe have a mix of them, take this into account in your scenario’s
• SMB-related security settings like signing and so on also affect performances
• Other security configuration like TCP/IP stack hardening or IPSec
• The presence of a file-based Anti-virus: it is wise to test with and without. You might be surprised by the performance loss an A-V implies, particularly on heavily used servers of course. BTW, since most of (if not all) A-V are implemented as file system filter driver, do not simply disable it during the tests, uninstall it, for certainty
• Take into account the other side-activities, particularly server-side like: backups (using shadow copies or third party solutions), monitoring or other background processing tasks that may affect tests (reporting and so on…)
• So called “performance-boost” tweaks like cache manager, NTFS tweaks, disk alignment, cluster sizes… All-in all, they may greatly affect the results. BTW, I will dedicate another post to those tweaks and debunk some myths at the same time as well

What do you get from the tests?

Besides generating the load itself, FSCT, assuming you’re working in a standard setup, will provide detailed tests results containing the following useful information’s retrieved from the server and client(s):

Data collected from the following performance counters:

• \Processor(_Total)\% Processor Time
• \PhysicalDisk(_Total)\Disk Write Bytes/sec
• \PhysicalDisk(_Total)\Disk Read Bytes/sec
• \Memory\Available Mbytes
• \Processor(_Total)\% Privileged Time
• \Processor(_Total)\% User Time
• \System\Context Switches/sec
• \System\System Calls/sec
• \PhysicalDisk(_Total)\Avg. Disk Queue Length
• \TCPv4\Segments Retransmitted/sec
• \PhysicalDisk(_Total)\Avg. Disk Bytes/Read
• \PhysicalDisk(_Total)\Avg. Disk Bytes/Write
• \PhysicalDisk(_Total)\Disk Reads/sec
• \PhysicalDisk(_Total)\Disk Writes/sec
• \PhysicalDisk(_Total)\Avg. Disk sec/Read
• \PhysicalDisk(_Total)\Avg. Disk sec/Write

As well as the following metrics (correlated to the number of users simulated):

• % Overload
• Throughput
• # Errors
• % Errors
• Duration in ms

Once the % Overload is higher than 0%, it will indicate the threshold above which your file server infrastructure does not scale anymore for the given number of users

Special Cases

Using FSCT against DFS-N

Can FSCT work against DFS-N: yes it does. But it will not allow you to stress-test the DFS part of your design since it has no knowledge of it and does no embark any technology to capture DFS’ behavior during the load test. Moreover, it may require to configure the “server” part as if it was a non-Microsoft file server (see below for details). Moreover, capturing performance counters on the server using FSCT itself might be an issue, the workaround being the good old “manual” capture using perform or logman.

Using FSCT against a failover cluster

Using FSCT against a failover cluster works perfectly but with one limitation identical as above: the tool will ne be able to collect performance counters directly. Instead, you will have to plan for manual capture on the node designated as owner of the file share resource, or on both if you wish to perform failovers during the tests.

Using FSCT against non-Microsoft File Server or NAS

Assuming you can leave with the same limitations as stated above, FSCT will work like a charm against non-MS file server, including SOHO devices. Depending on the server or device’ capabilities, you might be able to collect a reduced set of performance indicators using SNMP polling for example. Of course, FSCT itself does not include any SNMP but there are plenty of tools available and during the test I lead Cacti was very helpful.

Ready, Go?

Well, not 100% ready yet. The only workload scenario available at RTM release time being “Home Folders”, you might not be able to validate your setup realistically. But according to MS, an SDK is on the way in order to allow the creation of custom workloads. In the mean time, you can already start playing with the tool itself and with the customization of “HomeFolder” profile config file but you will not go far with that.

Additional Resources

• MS Download – File Server Capacity Tool 32-bit or 64-bit (includes step-by-step guidance)
• Jose Barreto’s Blog (MS) - “FSCT” - A CIFS/SMB/SMB2 File Server Tool for Capacity Planning and Performance Troubleshooting
• Cacti 

In a coming post I will cover practical usage of FSCT.

Marc

Beyond the discussion over the pro’s and con’s of SharePoint Designer, you may sometimes have to prevent its usage in order to comply with the policies or governance in place in your organization. Although you can block it from the client-side (using software restriction policies or Office ADM files), the most efficient measures (talking about enforcement) remain on the server-side.

Disable “Remote Interfaces” at Web Application Level

From the SharePoint Central Administration Web Site, you can modify the “Permissions for Web Application” and uncheck “Remote Interfaces”.

• Pro’s: Simple, no code, config only
• Con’s: will not only block SharePoint Designer but ALL “rich” protocols: WebDAV, Soap, FPRPC… No more Explorer View, RSS Feed, working from Office or “Edit in Office menu options”…

Lock Site Definition in ONET.XML

Modifying The configuration or each site definition in ONET.XML (adding the attribute DisableWebDesignFeatures=”wdfopensite” to each Project tag) will prevent customization using SP Designer.

• Pro’s: Offers granularity per site definition
• Con’s: Manual edition of ONET.XML by default… Up to you to package it properly otherwise.

Manage Permission at Site-Level

Add and Customize Pages: Removing this permission will prevent edition of pages that are not stored as list items (default.aspx and so on)

Browse Directories: disabling this option will simply prevent SPD to open a site… But it will also break other WebDAV clients!

Manage Lists: Disabling this permission will prevent some kind of modification from SPD but will not prevent its global usage. Moreover, it will also break simple browser-based advanced list edition…

• Pro’s: Offers granularity per site.
• Con’s: does not scale for large farms with lots of sites. Light break other functionalities or might not totally lock down SPD Usage… Better be prepared with a bullet-proof functional test matrix ;)

Using ISAPI Filter and User Agent String: UrlScan3.1

Since version 3.0, UrlScan tools comes with rich pattern-based request blocking options. To reject request originating from FrontPage Designer, add the following elements to the configuration file (UrlScan.ini):

RuleList=DenyUserAgent

[DenyUserAgent]
DenyDataSection=Agent Strings
ScanHeaders=User-Agent

[Agent Strings]
MS FrontPage 12.0

• Pro’s: Easy to deploy and to configure. Excellent performances. Participates to the overall effort to secure the platform. Includes logging (own and IIS W3C files). Relatively granular deployment possible (per web application)
• Con’s: Remains at ISAPI-level. No rich authorization options (based on user identity, membership…). Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using ISAPI Filter and User Agent String: Make your own

“Simplistic” example below. Ready to be compiled. Do not forget to chose the appropriate platform (32 or 64-bit) depending on your destination server.

#include <windows.h>
#include <httpfilt.h>

BOOL GetFilterVersion(HTTP_FILTER_VERSION *pVer)
{
  pVer->dwFlags = (SF_NOTIFY_PREPROC_HEADERS | SF_NOTIFY_AUTHENTICATION |
             SF_NOTIFY_URL_MAP  | SF_NOTIFY_SEND_RAW_DATA | SF_NOTIFY_LOG  | SF_NOTIFY_END_OF_NET_SESSION );
  pVer->dwFilterVersion = HTTP_FILTER_REVISION;
  strcpy(pVer->lpszFilterDesc, "SharePoint Designer Blocking ISAPI, Version 1.0");
  return TRUE;
}

DWORD WINAPI __stdcall HttpFilterProc(HTTP_FILTER_CONTEXT *pfc, DWORD NotificationType, VOID *pvData)
{
    char buffer[256];
    DWORD buffSize = sizeof(buffer);
    HTTP_FILTER_PREPROC_HEADERS *p;
    switch (NotificationType)  {

      case SF_NOTIFY_PREPROC_HEADERS :
      p = (HTTP_FILTER_PREPROC_HEADERS *)pvData;
      BOOL bHeader = p->GetHeader(pfc,"User-Agent:",buffer,&buffSize);
      CString UserAgent(buffer);
      if(UserAgent.Find("MS FrontPage 12.0") != -1) {
          p->ServerSupportFunction( pfc, SF_REQ_SEND_RESPONSE_HEADER, (PVOID) "403 Forbidden" , (ULONG_PTR)"Content-Length: 0\r\nContent-Type: text/html\r\n\r\n", NULL );
      }
      return SF_STATUS_REQ_HANDLED_NOTIFICATION;
    }
    return SF_STATUS_REQ_NEXT_NOTIFICATION;
}

• Pro’s: Easy to deploy. Excellent performances
• Con’s: Requires code and appropriate compilation. Limited functionalities, hard to code compared to HTTP modules/handlers. No logging, totally blind operations. Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using HTTP Module and User Agent String: Make your own too

HTTP modules are "roughly the .Net translation of ISAPI with tons of extra capabilities. “Simple” example below.

using System;
using System.Web;

namespace BlockSPD
{
    public class BlockSPDHttpModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(BeginRequest);
        }
        private void BeginRequest(object sender, EventArgs e)
        {
            HttpContext currentContext = HttpContext.Current;

            if (currentContext.Request.UserAgent != null && currentContext.Request.UserAgent.Contains("MS FrontPage 12.0"))
            {
                currentContext.Response.StatusCode = 403;
                currentContext.Response.StatusDescription = "Forbidden";
                currentContext.Response.End();
            }
        }
        public void Dispose()
        {    
        }
    }
}

• Pro’s: Easily to develop and relatively easy to deploy. High flexibility for extra conditions: user’s identity, group membership, URL accessed… with minimal effort compared to ISAPI
• Con’s: Requires code. Implies more processing overhead than ISAPI. No logging, totally blind operations. Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using HTTP Module and User Agent String: Cool CodePlex projects

Don’t want to waste your time playing around with own modules/handlers, take a look at these ones from CodePlex:

• Block SharePoint Designer HttpModule: This module includes authorization based on registry keys secured using AD-based groups. Very mature package.
• No SharePoint Designer: HTTP Handler, packaged as a feature. More controls over sites/URLs

More options using ISAPI, Modules, handlers or URLScan…

The technologies described above can also be used to reject requests that can be considered as “typical” fro SPD:

- Rejecting request whose URL ends with “/_vti_bin/_vti_aut/author.dll"

- Rejecting verbs or request that are typical from the FrontPageRPC procotol

In both cases, you might also block valid request coming from OFfice applications such as Word or Excel though…

Additional Resources

• Microsoft SharePoint Designer Team Blog: Options for locking down SharePoint Designer
• IIS.NEt: Using URLScan
• MS Support Knowledge Base Article: How to prevent SharePoint Designer 2007 users from changing a Windows SharePoint Services 3.0 site or a SharePoint Server 2007 site
• MS Support Knowledge Base Article: INFO: ASP.NET HTTP Modules and HTTP Handlers Overview
• MS Support Knowledge Base Article: How To Create an ASP.NET HTTP Module Using Visual C# .NET
• MSDN: Internet Server API (ISAPI) Extensions
• MSDN: SharePoint Products and Technologies Protocols

Marc