Tales from a SharePoint farm

I've moved!

noreply@blogger.com (Benjamin Athawes) — Wed, 18 Aug 2010 18:57:00 +0000

Dear followers,

FPWeb has kindly provided me with a shiny new SharePoint 2010 site over at www.benjaminathawes.com/blog.

As such, all future blog posts will be published there.

This blog will not go away, but please update your RSS feeds. This is the new feed.

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

WFE Application Pool Limitations in SharePoint 2010 (Part 2)

noreply@blogger.com (Benjamin Athawes) — Wed, 04 Aug 2010 20:46:00 +0000

Recent related blogs that might interest you:

16/02/2010 Update: Having recently been to a SP2010 admin course with Combined Knowledge, I took the opportunity to discuss this with @SteveSmithCK who has suggested that for now we should ensure farms are in a supported state and stick to the MS documented limit of 10 app pools in total (i.e. Portal content AND Service app end points). I will update this post if Microsoft do change the SP2010 software boundaries Technet article to clarify this point. I would say that the article is currently ambiguous and open to interpretation - especially given that it states that "The maximum number is determined by hardware capabilities". Only the Microsoft product team can really answer this question once and for all.

22/12/2010 Update: Note that this blog post refers to application pools used for hosting content Web applications only, NOT those hosting service application end-points. This article by @jremmc explores the differences between the two - check it out!

A couple of weeks ago I blogged about the application pool limitations in SharePoint 2010 based on a discussion I had with @SteveSmithCK at the #SUGUK. Since then, I have been on vacation in Iceland and received a number of related comments from members the SharePoint community. You can read the original post here; in this post I will aim to provide a concise summary with some revised best practise recommendations.

The key points, which were kindly sent to me by @SteveSmithCK and @harbars are that:

The TechNet recommended maximum number of Web server applications pools is 10, which is correct.
The IIS 7.5 limit of 100 pools with Windows Server 2008 R2 x64 is correct - but that limit is not applicable to SharePoint as there are so many other factors to consider.
The point of scale in a Sharepoint farm is not simply the Web servers, but rather a combination of factors including farm usage, number of servers and hardware capability.
Administrators should be questioning why a large number of application pools / Web applications is required, as opposed to why there is a recommended limit of 10.

Both Steve and Spencer made a point of emphasising that performance issues will likely be encountered even before 10 application pools is hit: "If you had 5 App pools all busy then you could easily consume 24GB+ of memory and all four cores very easily on a 64bit WFE Server". So although 10 is the documented figure, it is neither a "magic number" nor a hard limit imposed by the software and depends largely on farm usage (think user requests and service applications, particularly resource hogs such as Performance Point).

Although probably a topic for a future blog post, I think the fourth point above (from Spencer) is particularly interesting. TechNet document a number of reasons why administrators may wish to create additional IIS 7 application pools including grouping similarly configured sites and isolating those with unique configuration settings or security requirements. In the context of SharePoint, the primary reasons I have come across in the past for additional application pools are:

Isolating SharePoint Web applications for security-sensitive clients.
Isolating SharePoint Web applications that are prone to problems in order to provide protection from cross-site failure (e.g. features, custom Web parts) due to a shared application pool.

I think that there is some validity in the first point for clients that have very stringent security requirements and expect their data to be completely isolated - we have dealt with clients in the past that have requested separate pool identities as part of their corporate security review. However, one could argue that the new multi-tenancy features in SharePoint 2010 (site subscriptions, service application partitioning, host-named site collections; more over at harber.net) provide a solution to this problem and should help keep the number of required Web applications to a minimum. Remember that more Web applications always means more timer jobs and higher hardware demands - particularly if using a separate IIS application pool and associated worker process.

I think there will always be a place for an isolated application pool for troublesome sites and applications. Although numerous features in SharePoint 2010 should lead to higher availability (e.g. sandboxed solutions, list and HTTP throttling), I am sure that there will still be occasions where farm-wide custom solutions cause issues (e.g. a problematic Web part deployed to the GAC).

Another reason that IIS sites are typically placed in a separate application pool is differing .NET version requirements. This wasn't really relevant to MOSS given that versions 2.0 through 3.5 used the same version of the CLR (see this post for more information), but could be relevant to SharePoint 2010 going forward if Microsoft release an update that supports ASP.NET 4.0.

To summarise, the TechNet recommended maximum of 10 application pools is correct and great care should be taken in planning the creation of new application pools and corresponding Web applications. SharePoint portal application pools can eat a considerable amount of RAM and can bring down even the meanest Web server if deployed without proper planning. As a best practise, the number of pools and Web applications should be kept to a minimum in order to increase farm performance - I think it's worth remembering that site collections are the unit of scale in SharePoint (2000 per content DB recommended maximum) and the new multi-tenancy features in the 2010 version of the product should be utilised in order to deploy an appropriate (scalable) logical architecture.

I hope that helps to clarify things - thanks to @SteveSmithCK and @harbars for their input on this.

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

WFE Application Pool Limitations in SharePoint 2010

noreply@blogger.com (Benjamin Athawes) — Sat, 24 Jul 2010 19:49:00 +0000

Note: an updated version of this post with revised recommendations is available here.

As the agenda looked so interesting I decided to drive to Ullesthorpe (home of Combined Knowledge in the midlands) on July 22 2010 to the SharePoint User Group UK (#SUGUK). Considering I live in West Berkshire (and drive a 1993 Ford Fiesta, which I am rather fond of) this turned out to be a 5 hour round trip. Was it worth it? Hell yes! In addition to two very different - but fantastic - presentations from @mattgroves (big on social and lead me to believe that SharePoint is in fact an elephant) and @SteveSmithCK (capacity planning extraordinaire), I managed to win myself a 12-month MSDN subscription! Given that the question was basically "who has the rights to deploy a sandboxed solution in SharePoint 2010?", I consider myself very lucky to have won given the number of other SharePoint addicts sat in the room with me. I think the fact that most of the other attendees appeared to already have one (I heard someone behind me talking about how she planned to give her "spares" away) helped considerably.

However, whilst I enjoyed both presentations thoroughly, one question from the audience troubled me somewhat: "is there a limit to the number of application pools you can host on each WFE server in SharePoint 2010"? While Steve's answer was "around 100 before you start to run into IIS issues", I couldn't help but shake a nagging feeling that I had read the TechNet recommended maximum was 10. In fact, I was so damn sure of that TechNet number (10 app pools / WFE) that I would have bet my brand new MSDN subscription on it.

Now I was faced with a dilemma here: did I take Steve Smith's guidance as gospel, or go with Microsoft's recommendation? I did what I figured every sensible SharePoint administrator would do in my situation: I sat down, got back in my box and reminded myself that on the odd occasion TechNet tells more fibs than my parents used to on Christmas eve.

I did however make a point of looking up the TechNet article in question this evening. It does indeed list 10 application pools per Web server as a recommended guideline - in this case the "Limit type" column indicates the figure is a supportability number. Now, I know MS supportability numbers and they are not typically less than you would expect - and I would certainly not expect it to be ten times less than the guidance provided by a SharePoint legend such as Steve Smith. As a recent example, @harbars kindly informed me that having over 50 Web applications in one MOSS farm was, in his words (tweet) "madness" - Microsoft recommend no more than 99 Web applications. I think you know which guidance I paid attention to and he doesn't live in Redmond.

To be fair to Microsoft, the article above does also state that the maximum number is largely determined by hardware capabilities and the workload that the farm is serving. Steve also confirmed this at the user group by telling me that the app pool ceiling has been lifted dramatically due to the move to a 64-bit-only architecture for SharePoint 2010. Now I know that 64-bit brings about numerous performance and scalability benefits (not least of which is a practically unlimited, continuous address space for user mode processes), but I am still keen to find out why there is such a huge discrepancy between Microsoft's stated supportability figure and the guidance of industry experts who have used the product for the best part of 2 years.

So, rather than pester Steve again, I did what I often do when I have a nagging capacity-related query: I sent the query to a few friendly folk in the SharePoint community who (despite the fact that they are quite clearly very, very busy people) normally find the time to respond to my numerous concerns. Did anyone reply this time? You bet.

@ToddKlindt gave me a pretty clear response by saying that "anything Steve says, I believe". Sounds like good advice right? He also told me that the documented MS advice was actually pretty good considering that they suggest the limitation is largely hardware dependant. For those of you that don't know Todd, he is a well respected SharePoint guru and a co-author for Professional SharePoint 2010 Administration. If you don't have it already and you are a SharePoint 2010 administrator I can whole-heartedly recommend that you add this to your one to your collection of geeky paperbacks.

@joeloleson's article entitled "What’s New in SharePoint 2010 Capacity Planning" also mirrors the advice kindly provided by Steve and Todd. Joel points out that Microsoft have adjusted some of their capacity planning guidance based simply on the fact that IIS and SQL scale better with 64-bit, and states that the number of application pools " totally depends on the RAM on the box".

So how many Web applications can you host on a SharePoint 2010 WFE server? It looks like the usual SharePoint consultancy response: "it depends on your hardware's capability and server farm load", and there is no magic number other than the guidance provided by Steve that you may run into IIS issues as you approach 100 pools on one server. Microsoft's supportability number of 10 is there as a rough guide (probably for those running a minimal WFE hardware configuration - think 8GB of RAM), but is almost completely dependent on your available hardware. The new SharePoint 2010 Administration Toolkit includes a load testing kit that should help administrators validate their hardware requirements as part of a capacity planning exercise.

I hope that clears things up a little bit for anyone else concerned that they have more than 10 application pools on their SharePoint 2010 WFE servers. I'll see you at the next #SUGUK!

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

SharePoint disaster recovery on a budget

noreply@blogger.com (Benjamin Athawes) — Tue, 20 Jul 2010 00:33:00 +0000

A post over on the MSDN forums got me thinking about disaster recovery in SharePoint. I thought I would share my thoughts with you given that availability and disaster recovery are important concepts to anyone hosting (or using) SharePoint. Throughout the article I use information contained in the 2010 and 2007 technet articles entitled "Plan for availability".

In the forum post, the OP asks for feedback on his SharePoint 2007 DR strategy:

The farm consists of two physical DB servers and two physical Web servers. One physical Web server is virtualised meaning there are 3 Web servers in total. Note that it is assumed that these servers also host the query and index role.
There is a very limited budget (as is often the case) in that only one server has been approved for DR purposes.
No availability (e.g. uptime %) requirements are specified.
No capacity (e.g. number of users, RPS) requirements are specified.
The OP plans to implement a "stretched farm" over a WAN link. We can assume here that they are not closely linked as it is stated that that backup server is "in another part of the world". The DR server would be added to the farm as a Web server, and other roles would be added if required.

Frankly, being given an entire server in a separate data centre for DR purposes is more than a lot of SharePoint administrators could hope for. Although in an ideal world we would all have a completely redundant DR farm in a nearby data centre on hot standby, the OPs question is a lot closer to reality for most organisations.

However, I did think of a few potential issues with the OPs suggestion:

Stretched farms are only a realistic scenario where they are in close proximity with high speed links. That means less then 1ms latency and 1GB/s bandwidth.
The SharePoint configuration and central administration content databases contain computer-specific information meaning that the restoration environment must contain the same topology and server roles - which would not be possible on a single server.
There is no mention of the other SharePoint infrastructure requirements, including DNS and a user directory, although we will assume for this scenario that the OP has included those services as part of their DR strategy anyway.
Aggregate capacity requirements need to be met on the single DR server for the duration of the servers use. This means whatever resources were used on the "live" farm servers need to be available on the standby. Amongst others this includes CPU cycles, RAM, disk capacity, disk IO requirements, and network bandwidth.

Sample aggregate resource requirements

Note that the aggregate totals displayed here are simply for the minimum system requirements and do not include network and disk capacity. Realistically, each server may well have a lot more hardware resources. For example, assuming each server has 8GB of RAM, 100GB of disk capacity and a 3Ghz dual core CPU (not uncommon in modern MOSS 64-bit environments) , the requirements are suddenly a lot tougher to meet on a budget: the OP would need a server with 40GB of RAM, 500GB disk space and a 10 core CPU!

From these observations I concluded that:

A separate standby farm is required - as we only have one server available this will be a standalone server with all roles on one box.
The standby server needs to meet the aggregate capacity requirements provided by the existing servers for the duration of the outage.

The standby type (cold, warm, hot) depends on the OPs availability requirements. These are detailed in Plan for disaster recovery (SharePoint Server 2010). Given that there is clearly a limited budget, one can assume that maintenance and configuration costs need to be kept to a minimum, in which case a hybrid approach seems preferable. Here is one possible approach based on Microsoft's guidance in provisioning a hot standby data centre:

Create a separate DR farm and apply all Windows, SQL, WSS and MOSS updates to match that of the live environment as closely as possible.
Deploy all SharePoint customisations to the DR farm
Create and configure all Web applications to the DR farm, restoring all content databases from the live farm.
Test it!

Going forward, the maintenance required really depends on required availability. If the business can't cope without SharePoint for more than a few hours than the OP needs to consider configuring SQL log shipping to ensure his content databases are synchronised, and will need to ensure all live updates are also deployed to the DR server at all times. If, on the other hand a day's worth of downtime is acceptable the OP may decide to simply document any live changes and deploy them to the DR server on an "as-need" basis.

Of course, this is just one possible approach. If you have any suggestions or improvements I'd like to hear them!

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Multi-Tenancy in SharePoint 2010 using host-named site collections

noreply@blogger.com (Benjamin Athawes) — Wed, 07 Jul 2010 22:39:00 +0000

Having just received our SharePoint 2010 Evolution Conference DVDs, I couldn't resist browsing through the vast quantity of slide decks provided by Combined Knowledge. Spencer Harbar's deck on Multi-tenancy immediately grabbed my attention given that hosting is a core part of what we do.

Multi-tenancy in the context of SharePoint is Microsoft's term for "hosting". In SharePoint 2007 (MOSS), hosting a SharePoint environment with multiple tenants was a significant challenge. Issues included a limitation on the number of Web applications that could be created, site collection management / isolation problems and URL namespace restrictions.

In SharePoint 2010, Microsoft have to a large extent dealt with the last two issues mentioned above. Creating a large number of Web applications within a single farm still causes resource problems so the preferred scaling approach for hosting companies is likely to be to go with site collections - especially considering they can now be partitioned and managed by tenants themselves.

Host-named site collections in MOSS were generally considered a no-go. On paper, they did not support managed paths or SSL termination. In practise, they were fraught with issues and administrators generally avoided using them.

So what's changed for host-named site collections in SharePoint 2010? In short, they are fixed. By this, I mean:

· Managed paths are now supported.
· Off-box SSL termination is now supported.

This makes it entirely possible to have "vanity URLs" on a per site collection basis. For example (domain name ownership issues aside), you could have www.microsoft.com for one site collection and www.ibm.com on another - within the same Web application.

I should mention at this point that there is one limitation around host-named site collections that you should be aware of: they do not support alternate access mappings and are therefore always considered to be in the default zone. Additionally, host headers cannot be applied at the Web application (IIS site) level, and doing so makes it impossible to access host-named site collections (IIS ignores requests that do not match the host binding). Read more on Technet.

Demo: setting up multiple host-named site collections in one Web app

Prerequisites:

· A SharePoint 2010 test server (foundation will do).
· Access to PowerShell.
· A Web application that does not have a host header applied at the IIS Web site level.

DNS Entries for vanity URLs

OK so I dont imagine setting up a couple of DNS entries is going to be tricky for the IT pros out there. However, I will include this step for those who may not be familiar with DNS administration.

Add new forward lookup zones for your vanity URL domains, e.g. "microsoft.com" and "ibm.com".
Within each lookup zone created above, add a new host, e.g. "www" with an IP for your test server. On my test VPC I just added 127.0.0.1.

DNS entries for vanity URLs

Create Web application

If you don't have an appropriate test Web application, go ahead and create one. Ensure that you do not apply a host header at this stage.

Ensure you don't apply a site level host header

Create host-named site collections using PowerShell

Open up the SharePoint 2010 Management Shell and enter the following commands to create a new site collection for each of your desired vanity URLs. In this case I have created a site collection with the host name www.microsoft.com:

New-SPSite http://www.microsoft.com -OwnerAlias DOMAIN\username -HostHeaderWebApplication http://servername

Entering the PowerShell commands; don't forget the dash before HostHeaderWebApplication!

You should now be able to access your new site collections using the vanity URLs you have specified. You have successfully created multiple host-named site collections within one Web application demonstrating the use of vanity URLs to cater for multi-tenant scenarios in a scalable manner.

All done - your new host-named site collections should be accessible

Summary

Host-named site collections are vastly improved in SharePoint 2010 when compared to previous versions. This, combined with the other benefits mentioned above such as improved tenant administration and data partitioning for site collections provides a compelling case for hosting companies to upgrade. If you are interested in multi-tenancy in SharePoint 2010 I would strongly recommend you check out Spencer's post linked at the beginning of this post.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Administration: Supported Database Operations in SharePoint 2010

noreply@blogger.com (Benjamin Athawes) — Sun, 20 Jun 2010 10:58:00 +0000

Edit (13/08/2010)

@joeloleoson Expands this article by explaining how vendors use Microsoft’s protocol documentation to "do things not readily exposed in the object model" on his blog. I recommend you have a read.

=========

I have seen a few queries recently around which database operations are supported in SharePoint. As SharePoint administrators, we need to be aware of which operations should be run on farm databases in order to ensure good farm health and performance - and which operations we should avoid at all costs in order to keep databases in a supported state.

Whilst I might take a slightly more relaxed approach in development environments with regard to database operations (I don't expect support from Microsoft for my VPC), my rule in a production environment is clear: never, ever perform an unsupported operation unless specifically asked to by Microsoft support. That includes reading from a content database - which might surprise some.

That's right - reading from a SharePoint DB will leave it in an unsupported state. That's confirmed in this KB article that was updated in April of this year and applies to pretty much any SharePoint product since WSS 2.0 up to and including SharePoint Server 2010 (with the exception of the logging database, where customisations are fully supported).

If you a take moment and think about this, prohibiting changes to the DB schema actually makes a lot of sense. Microsoft tests SharePoint based on a specific database schema and could not possibly predict changes that third parties are likely to make. Therefore, it could not practically support those changes. I think of this as analogous to purchasing a new BMW Z4, fitting a supercharger and then expecting the dealer to honour any warranty they may have promised - it just would not be practical nor economically viable.

As regards to preventing read operations (e.g. SELECT statements), I suppose that it's analogous to breaking the warranty sticker on an electrical appliance. OK, you may not have touched anything but it implies you may have done. Similarly, if Microsoft discover that you have been taking a look through a content database they would be inclined to think you have made a few changes along the way.

So we know that reading from a SharePoint database is prohibited. Here are a few other operations that Microsoft specifically list in the above KB article as leaving a database in an unsupported state:

• Adding database triggers

• Adding new indexes or changing existing indexes within tables

• Adding, changing, or deleting any primary or foreign key relationships

• Changing or deleting existing stored procedures

• Calling existing stored procedures directly

• Adding new stored procedures

• Adding, changing, or deleting any data in any table of any of the databases for the products that are listed in the "Applies to" section

• Adding, changing, or deleting any columns in any table of any of the databases for the products that are listed in the "Applies to" section

• Making any modification to the database schema

• Adding tables to any of the databases for the products that are listed in the "Applies to" section

• Changing the database collation

• Running DBCC_CHECKDB WITH REPAIR_ALLOW_DATA_LOSS (However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.)

I recommend you read the KB article linked above for the most up to date list of (un)supported operations.

So which operations can we perform on a SharePoint database? The SQL DBA's out there will know that routine maintenance is essential for optimum performance - and few areas are as important to SharePoint performance than the SQL back end. Whilst I have not yet seen an equivalent resource for SharePoint 2010, Microsoft published a very useful white paper back in November 2009 called "Database Maintenance for Office SharePoint Server 2007". I encourage you to take a look if you haven't seen this already and are involved in MOSS administration (although I imagine it will be relevant to SharePoint 2010 also).

According to this white paper, the following maintenance tasks are recommended:

• Checking database integrity (ensures that your data and indexes are not corrupted).

• Defragmenting indexes by either reorganizing them or rebuilding them (applies mainly to indexes; fragmentation can be reduced by setting a large database start size).

• Setting the fill factor for a server (allows index performance to be fine tuned).

• Shrinking databases to recover unused disk space (white space caused by deleting documents, libraries, lists etc.).

Note that Microsoft do not recommend configuring auto-shrink operations, and advise only to shrink content databases due to the fact that other types of databases (e.g. SSP) do not typically undergo a large number of deletions.

In conclusion, things haven't really changed much since MOSS with regard to which DB operations are supported - the main message is to keep well away from them! I imagine Microsoft will release a similar resource for SharePoint 2010 with an updated list of recommended DB maintenance operations. For now, I will be implementing the above MOSS maintenance plans on my SharePoint 2010 test environment.

SharePoint 2010 and .NET 4: confused?

noreply@blogger.com (Benjamin Athawes) — Sat, 19 Jun 2010 17:47:00 +0000

I have seen a few queries on the Technet forums recently regarding the use of ASP.NET 4 and SharePoint, an example being this post here.

There appears to be some confusion (myself included) around whether or not ASP.NET 4 is supported for both MOSS and SharePoint 2010 - in short, the answer is that it is not currently supported in either product.

Whilst it is possible to use ASP.NET 3.5 in MOSS by making some modifications to the SharePoint site web.config (instructions for doing that in MOSS here; SP2010 uses 3.5 by default), this is unfortunately not the case with version 4.

The reason? ASP.NET 4 uses a new version of the Common Language Runtime (CLR). Whilst .NET 2.0, 3.0 and 3.5 all used version 2.0 of the CLR, .NET 4 uses version 4. I'm not entirely sure what happened to version 3. There is a decent post on stack overflow with further details.

For those that are wondering, the fact that .NET 3.0 and 3.5 do not show up as options within IIS is also related to the CLR version. IIS knows about that - it does not know about framework and compiler versions and the aspnet_isapi.dll from the version 2.0 is used for version 2.0 through 3.5 for this reason. This post explains that in more detail. Does that mean we will get a new option in IIS for .NET 4? You bet, due to the use of CLR v4.

So does that mean we are destined to use .NET 3.5 for the lifetime of SharePoint 2010? Not necessarily. Aside from the possibility of Microsoft adding support for version 4 in a future service pack, those using ASP.NET Web forms in separate virtual directories will still be able to use .NET 4 so long as said virtual directories are in a separate application pool. I have confirmed this is the case with Microsoft in this post, and believe this to be the case for SharePoint 2010.

I hope that helps clarify things a little.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Extranets: SharePoint 2010 Gateway and Firewall Products

noreply@blogger.com (Benjamin Athawes) — Thu, 17 Jun 2010 20:47:00 +0000

While there is already an abundance of information available online regarding SharePoint 2010, I had not seen much related information on gateway products until this afternoon. Considering the improvements made to Web hosting in SharePoint 2010, I thought it worth taking a look at the various supported options available and determine whether there is much difference when compared to those available at the time MOSS was released back in 2007. The most notable changes since then are that TMG 2010 is effectively the replacement for ISA server 2006 (although ISA 2006 is still tested and supported in SharePoint 2010), and ForeFront UAG 2010 replaces IAG 2007.

Wikipedia defines an extranet by stating that "An extranet can be viewed as part of a company's intranet that is extended to users outside the company, usually via the Internet". In the context of SharePoint, I interpret this as the ability to securely publish SharePoint resources over the Internet in order to provide access to users outside of the company infrastructure.

There are numerous reasons that companies may wish to use a firewall or gateway product to publish SharePoint resources; in my experience this has typically been to provide secure remote access to external staff and customers including those using mobile devices. One product that I have worked with in the past to facilitate this is ISA Server. As with MOSS, Microsoft have tested ISA server with SharePoint 2010 and provide a useful comparison between this, ForeFront TMG and ForeFront UAG here. One area that caught my attention was Web hosting: in SP2010, hosting providers are supposedly "first class citizens" with the introduction of data partitioning and service subscriptions to facilitate multi-tenancy. With this in mind, it seems likely that hosted service provides will want to consider a secure method of publishing their server farm to remote users using a gateway product such as Forefront UAG 2010.

Looking at the comparison provided by Microsoft in the above document, one might wonder why businesses would bother upgrading to Forefront TMG when they are already using ISA server 2006. After all, the only additional feature advertised appears to be "DirectAccess" - and even that is only partially supported for TMG 2010.

John Wettern made some some interesting points back in 2009 that might lead us to think that perhaps TMG is a significant release, as opposed to the difference between ISA server 2004 and 2006 which (as John rightly points out) was little more than a service pack in terms of new features. Looking on the Forefront TMG Technet Blog reveals a couple of other documented benefits of TMG over ISA server 2006 - integrated anti malware protection and encrypted traffic inspection. DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that reportedly allows access to shared resources such as folders, e-mail servers and intranets without the need for a VPN.

Although the benefits here in using TMG over ISA are not really that relevant to securing a Web hosting service (which would likely benefit from the use of a reverse proxy server deployed in an edge firewall topology), I think the new features described in the above articles would certainly be useful to companies looking to deploy a gateway product in a back to back perimeter scenario for securing internal resources against the dangers faced online and improve accessibility to internal resources through DirectAccess. Indeed, Microsoft describe TMG as "a comprehensive, secure Web gateway that helps protect employees from Web-based threats" as opposed to UAG which "delivers secure, anywhere access to messaging, collaboration, and other resources, increasing productivity while maintaining compliance with policy".

So aside from the obvious benefit of an extended support period, there appear to be few compelling reasons for MOSS Web hosting providers to move from an existing reverse proxy scenario using ISA server 2006 to TMG 2010 when it comes to upgrading to SharePoint 2010 - indeed, you would only use TMG to protect internal users from Web based threats.

Lets move on to Forefront UAG 2010 - Microsoft's flagship gateway product that extends the features offered by TMG to include dedicated interfaces for mobile devices, health based authorisation and information leakage mitigation.

Microsoft provide a useful lists of benefits UAG brings to SharePoint here. This time the feature comparison appears to offer a more compelling reason to upgrade from ISA server 2006 in order to publish SharePoint 2010 resources - lets take a look at these features in the context of a provider looking to publish an extranet in a remote access scenario.

First up - information leakage mitigation. Having been through numerous penetration tests with prospective clients recently this one certainly sparked my interest. UAG deletes all cached files, temporary files and cookies which from a security perspective offers a compelling new feature when compared to ISA and TMG. Similarly, endpoint health-based authorisation offers an interesting corporate security improvement - particularly the capability to prevent unsupported (and potentially insecure) browser versions from accessing a published SharePoint site. It seems that these new security features will allow hosting service providers to proactively protect their sites in more ways than ever before.

Microsoft's inclusion of "Granular access policies" as an exclusive UAG feature in the comparison threw me slightly - having used ISA server 2006 extensively as an edge firewall I didn't see this is a new feature given that the ISA policy manager is extensive. I dug a little further on technet and can conclude that this feature mainly refers to the ability to target policies at specific platforms - such as Windows, Macintosh or Linux. I think that Microsoft's consideration for platforms other than Windows here demonstrates their change in approach toward competitors - a welcome change for customers that is consistent with the cross-browser support for SharePoint 2010.

In conclusion, customers planning to move to SharePoint 2010 that are looking to implement a gateway product to securely publish their server farm have more choice than ever before. While there are few obvious reasons to move from an existing ISA server 2006 based topology to TMG 2010, the extended features offered by UAG 2010 are a definite improvement and will allow providers to offer a very secure, policy based SharePoint installation to customers. Customers wishing to upgrade should note that UAG 2010 requires Windows Server 2008 R2 64-bit.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Administration: Stopping a SharePoint 2007 farm

noreply@blogger.com (Benjamin Athawes) — Sat, 05 Jun 2010 19:26:00 +0000

I noticed today that a fair number of people have found this blog by searching for something along the lines of "sharepoint stop farm procedure" or "how to stop sharepoint farm", particularly from one very well known search engine. I briefly described how to go about doing that in my post titled "Administration: Migrating to a new SQL Server in MOSS (SQL 2005 to 2008)".

I thought I would clarify this procedure in a little more detail given that it seems to be a common query.

Technet describes the procedure for stopping a SharePoint 2007 (MOSS) farm as follows:

Stop the farm by performing the following steps:

On the server that is running the Central Administration Web site, in the Services snap-in, stop the following services:

Windows SharePoint Services Administration service
Windows SharePoint Services Search service
Windows SharePoint Services Timer service
Windows SharePoint Services Tracing service
Windows SharePoint Services VSS Writer service

On the server that is running the Central Administration Web site, at the command prompt, type iisreset /stop.
Repeat step 6 on each server in the farm.

As you can see, the procedure involves first stopping all MOSS related services on your server(s) hosting the Central Administration Web site, stopping IIS then repeating the process on all WFE servers.

Whenever I have had to carry out this procedure I have created a simple batch script to automate the process and ensure I don't miss any services out. This is easily achieved by pasting the following into a notepad file and saving it as a .bat:

net stop "Windows SharePoint Services Administration" /y

net stop "Windows SharePoint Services Search" /y

net stop "Windows SharePoint Services Timer" /y

net stop "Windows SharePoint Services Tracing" /y

net stop "Windows SharePoint Services VSS Writer" /y

net stop "IIS Admin Service" /y

One other precaution I take to ensure the farm is inaccessible is to create a rule on the proxy server (e.g. the ISA Server array) to effectively block all Web access and present users with a useful error page.

I think it goes without saying that this process will prevent all access to a SharePoint server farm so should only be performed outside of peak hours with prior user notification.

I hope that helps!

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Virtualisation: Poor performance in VMWare Player or Workstation

noreply@blogger.com (Benjamin Athawes) — Sun, 30 May 2010 18:15:00 +0000

Since Microsoft have decided to throw us a curve ball with regard to 64-bit desktop virtualisation, I have recently been experimenting with VMWare Player as a replacement to MS VPC for SharePoint 2010 development. I noticed that almost every speaker at the SharePoint 2010 Evolution conference earlier this year was using the workstation version (required for commercial use) for demonstration purposes.

Whilst I am generally very happy with the VMWare software, one issue troubled me today. While the majority of the time my Virtual Machine performed satisfactorily, it did seem to "freeze" or hang every minute or so. During this time, the mouse and keyboard were unresponsive and I had no choice but to wait a few seconds for the machine to sort itself out.

After putting up with this for a few hours I became frustrated and decided to delve into the VMWare log (simply called "vmware") contained on the host machine, only to find the following:

============

May 30 17:31:49.154: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:42.095: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:42.107: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:46.692: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

============

To resolve this, I simply opened up the virtual machine settings and tweaked a few settings:

Unchecked "Connected" and "Connect at power on" for the Floppy device
Unchecked "Connected" and "Connect at power on" for the Sound Card device
Unchecked "Connected" and "Connect at power on" for the Printer device

Lo and behold - the problem disappeared instantly and I am now happily using my 64-bit VMWare VM!

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

My Quest SharePoint 2010 Virtual Expo notes

noreply@blogger.com (Benjamin Athawes) — Thu, 20 May 2010 10:17:00 +0000

Yesterday I had the pleasure of “attending” the Quest Virtual Expo for SharePoint 2010. Many thanks to Quest for hosting a very useful expo and to the presenters for answering almost every one of my questions. For those of you that attended, the slides and presentations are still available at unisfair.

Amongst the various presentations, I found these two particularly useful:

A Practical Guide to Managing SharePoint ( Joel Oleson)
Are you sure your deployment is ready for SharePoint 2010? (Rick Taylor and Joel Oleson)

Below are the notes I made from both of these sessions along with the Q&As that followed:

Presentation Notes:

In SharePoint 2010, each service application has its own database as opposed to the per-SSP model in MOSS. Spencer Harber wrote a good post about service applications which I encourage you to read through. My first thoughts on this are that while additional databases should mean greater flexibility and scalability, it may also mean additional storage requirements and administrative overheads. One benefit that springs to my mind is the ability to place service applications on different spindles based on predicted usage patterns which should mean better SQL performance.
The health monitoring and management capabilities in SP2010 look very useful for administrators. Joel showed us the automated password management capability within Central Admin which effectively means SharePoint can ensure password strength and renewal with no user intervention. This was a headache in MOSS and with new service applications I can imagine this will be a welcome new feature to ease administrative burden. Another new feature is a set of health rules which can be modified – these encourage Microsoft best practises to be followed and can be configured to send alerts through email or SMS. Not sure I would appreciate a text from our SharePoint farm alerting me to a best practise being broken but it’s a nice feature to include.
PowerShell allows management of SharePoint to be scripted – therefore allowing common administrative tasks to be repeated with less chance of human error. Joel mentioned that STSADM is still present in SP2010 but emphasised that PowerShell includes over 500 commandlets and should prove very useful.
Joel described the Microsoft SharePoint team’s “do no harm” upgrade planning philosophy in relation to PreUpgradeCheck and also mentioned that he is writing a book on migrations to SP2010.
Database upgrade methods were discussed – the general message was that in place upgrades are only really appropriate for small environments and even then should only be performed where a fall-back is possible. We certainly won’t be upgrading our physical servers using the in place approach any time soon! The DB attach method allows for a gradual upgrade process – and less downtime – making it (or a close hybrid) the approach we will be going with.
Separation of binary and visual upgrades in SP2010 mean that MOSS look and feel can be retained (2010 ships with MOSS master pages)
List throttling includes a “happy hour” feature that allows limits to be exceeded at a certain time of day. This should be useful for running intensive list item operations out of hours whilst retaining high performance during peak hours. Joel mentioned that “5000 is the new 2000″ (regarding the limit on the number of items in a list) – something that has been echoed in the Twitter community (e.g. @MirjamvanOlst). This is the maximum number of list or library items that a DB query can process at one time – more info here.
Sandboxed solutions are disabled by default
The dev dashboard includes an “ondemand” setting that allows it to be switched on and off. Enabled it displays debugging information at the bottom of a page that should be useful for identifying the cause of slow performance (e.g. SQL delay, rendering issues).
The OOB reporting capability in Central Administration allows the slowest pages across the entire farm to be identified, as well as “top users”.
Joel finished up by emphasising the benefits in running the PreUpgradeCheck tool that is available in MOSS SP2 and onwards, and mentioned that SP2010 Beta 2 VHD is available now for download.

Q&A Notes:

It is possible to exceed the 2 million user profile limit
It is not possible to migrate straight from SPS 2003 to SP2010
Virtualisation for SharePoint should start with WFE servers – you should hold off on virtualising SQL and index servers for now
The Microsoft recommendation of 16GB RAM per production server is recommended for Enterprise deployments but not necessarily a requirement for smaller farms. Rich Taylor gave an example of a 30,000 user deployment, predicting that 4 WFE servers each with 8GB may well be sufficient. The key message was that estimating hardware requirements is not straightforward and should be based on actual usage data (number of users, requests per second etc). Joel mentioned that there are performance and capacity case studies on TechNet – I believe he was referring to this information.
IE 6 is not supported for SP2010 but may be usable for a publishing environment with primarily read only content. A quick Google afterwards revealed this link that quite clearly depicts what various SP2010 sites look like in IE6 (awful!).
Rick and Joel gave no indication as to when SP2010 SP1 would be released but referred to the historical trend of “around every 9 months”. We were assured that there definitely will be an SP1
Licensing was briefly discussed – unfortunately it gets no easier with SP2010 and Joel mentioned that there are new SKUs with 2010 (I heard “Internet Standard Edition” mentioned but couldn’t confirm this online). Prices should be released next month.

I hope these notes are helpful – let me know if you have any feedback or queries.

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Development: Common MOSS coding issues based on MS recommendations

noreply@blogger.com (Benjamin Athawes) — Fri, 19 Mar 2010 20:16:00 +0000

Hi All,

Whilst browsing Sample code acceptance checklist for IT organizations on Technet, I realised that in several places we as an organisation were not always following best practises. As stated in this article, this probably means that we could do a few things to improve the performance and security of our product - and who doesn't want to write faster, safer code?

Here are the items that rang alarm bells and I thought it might be worth sharing them in case anyone else still has a few BP boxes to check:

Plain text passwords are not present in Web.config, Machine.config, or any files that contain configuration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting in AppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.

This often seems to slip through the net, reason being that administrators tend to think "Users can't get on our servers so what's the point?". The point, I think is that we as developers should always try to implement defence in depth security practises and this is a good example. OK - if an attacker somehow obtains RDP access to your server farm a plain text password for a Web application may well be the least of your worries but this is not a tricky one to fix. Grab Aspnet_setreg.exe and get to work!
If cookies contain sensitive data, they are marked secure.

The severity of missing this item depends on the sensitivity of your application and your supporting infrastructure. If your data must be secure during transit, then you need to either ensure that all cookies are marked secure, or you must ensure the channel is encrypted via some other means. Options that spring to mind are forcing this via IIS (straightforward in version 6.0 and later) and / or forcing an SSL redirect via a reverse proxy server such as ISA Server 2006. In our case, we implemented the last 2 options which ticked the corporate security check box when we conducted an external security review recently.
Input surfaces in Web parts and other customizations include boundary checks, input data integrity checks, and appropriate exception handling to protect from cross-site scripting and SQL injection.

OK, XSS and SQL injection are both well known security problems in Web applications. However, its always worth bearing these two common issues in mind and applying protective measures such restricting input (must be server side - think regular expressions) and using parametrised stored procedures. See How To: Protect From SQL Injection in ASP.NET for more info.
You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevated privileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, you ensure that AllowUnsafeUpdates is set to False in your try-catch-finally block, or you use a Dispose() method (as required by the IDisposable interface) to avoid security issues.

In the SharePoint development world, I believe it is relatively common knowledge that using AllowUnsafeUpdates liberally is a big no-no. However, there are places where it is unavoidable (sometimes whilst using SPLimitedWebPartManager) so ensure you utilise that finally block.
The ASP.NET validateRequest option is enabled, if possible.

Based on my experience, this appears to be a favourite item for penetration testers to pick on whilst testing ASP.NET forms applications. Enabling this option is a step toward preventing XSS (see How To: Prevent Cross-Site Scripting in ASP.NET).
The application consistently uses standardized input validation such as RegEx throughout.

I would like to confidently tell you that this requirement is a given and that I haven't come across an example where standardised input validation is neglected in recent years. However, that is simply not the case and I would encourage you to rigorously check and confirm that your ASP.NET controls are all validated using a white list input validation approach.
The application uses a standardized approach to structured error and exception handling throughout.
The code uses exception handling. The code catches only the exceptions that you know about. For example, do not use try{} catch(Exception ex){}unless you throw the error again.

I think that although many organisations do use a standardised approach to error and exception handling, it is sometimes an approach that is consistently wrong. For example, I have been guilty of doing this in the past:

catch (Exception ex)
{
throw (ex); // do NOT do this!
}

(this lesson here is that if you want to re-throw the exception currently handled by a parameter-less catch clause, use the throw statement without arguments see here)

The main point here is that you should review your code and ensure that your exception handling procedure is both consistent and follows best practises.
Application errors do not contain sensitive information or information that could be used to exploit the fault.

Quite often, this is viewed as a negative point as far as the end user experience is concerned. If a user fails to logon, they often want to know why they can't logon. As always, the problem here is striking a balance between usability and security. We want to help the user out by providing useful error messages, we really do. But we also want to prevent unauthorised access to your application and that has to take priority.

Throw generic error messages on-screen, but make sure you log as much detail about the error as possible to the log. Use proper exception handling to ensure the stack trace isn't lost.
Customizations are accompanied by a list of all dependencies. This could include account/passwords, Web services, databases, other solutions or Features, patches, tool sets or libraries, and other dependencies.

This might appear to be a relatively obvious point but I'm often surprised at how much information is retained in a developers head rather than correctly documented. The acid test is ensuring that someone outside of the development team can deploy the customisation without any issues.
When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.

I think this one speaks for itself, although this was a recent revelation for me.

I think that just about covers it. Please let me know if these items rang any alarm bells or if you have any comments.

Cheers, Ben.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Administration: Changing a MOSS Site's Application Pool

noreply@blogger.com (Benjamin Athawes) — Wed, 17 Mar 2010 22:31:00 +0000

Problem

Whilst developing a new version of our MOSS based product, we decided that we would like to isolate new sites by placing them in a brand new IIS 6.0 application pool. The idea behind this was to prevent issues on the new sites affecting clients on the old (stable) version of our product by running them in a new worker process.

While it would have been easy to opt to create a new Web application in our new application pool, we were faced with the problem of modifying an existing MOSS site to use a newly created pool. Note that I am not talking about change the identity of the application pool - this has already been documented on sites such as Eli Robillard's "World of Blog" - thanks Eli for the info.

When a member of our development team first asked me how to go about doing this, I incorrectly assumed that this would be as straightforward as going into IIS and modifying the properties of the MOSS Web site, having configured the appropriate SQL and group permissions (details of which are documented on technet).

However, having attempted this in our pre-production environment I can safely say this was simply not the case. Whatever I tried, SharePoint refused to allow me access to the site and greeted me with the standard MOSS access denied page. Taking a look online using a popular search engine, I found others had encounters similar issues but (as far as I could tell) had not come up with a solution.

Solution

The fix? In the end I simply had to delete and recreate the Web application. I created the process below which I hope others will find useful. Before you begin:

Backup your farm (i.e. full SQL backup)
Backup IIS on all WFE servers
Backup the web.config of the site you wish to modify the application pool for
Create the new application pool and document the new identity (service account) used
Document any custom Web parts that are deployed to the Web application
Document regional settings - e.g. time zone
Document authentication settings (e.g. Basic, Integrated)

As always, you should always test these steps in your own environment before using them in a real-world scenario:

1. Delete Web application in SharePoint Central Administration - do NOT delete the content database or IIS Web site just yet.

2. Delete IIS Web site

3. Create new Web application with new IIS site (making sure to select your brand new application pool) & note down default content DB name (to be deleted)

4. Perform an “IISreset /noforce”

5. Reconfigure your IIS settings (e.g. authentication providers, SSL certificate, host header bindings, home directory, logging, virtual directories)

5. Remove automatically created content db in SharePoint Central Administration

6. Confirm DB create date and delete temporary content db in SQL Server management studio.

7. Rename & Reattach correct content DB and confirm no. sites > 0 (could have attached the wrong content DB – minimal chance as I have checked all portal URLs)

8. Restore web.config (as SharePoint overwrites it upon creating a new Web application - you backed it up right?)

9. Add policy for web application if applicable

10. Redeploy web parts to all restored web applications if applicable

11. Set authentication providers

12. Set general settings (timezone) for restored web application

13. Set People picker settings for restored web application using STSADM

I think it's worth stating again that you should attempt these steps yourself in a test environment before attempting them on your production servers.

Feel free to let me know if you encounter any issues or whether these steps worked for you.

Cheers, Ben.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Development: Troubleshoot your #SharePoint custom Web services

noreply@blogger.com (Benjamin Athawes) — Fri, 30 Oct 2009 20:19:00 +0000

When I first read the W3C definition of a Web service back at university, I admit that it made little sense to me:

"a software system designed to support interoperable machine-to-machine interaction over a network...using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards".

How does one go about writing "SOAP-messages"? Would I have to serialise the XML myself? It all sounded rather daunting and, like most other students I settled for memorising the definition and a few benefits of using Web services.

However, having been employed as a SharePoint administrator come developer for some time now, I am pleased to say that writing a Web service, even one that is to be used in the context of WSS isn't all that difficult. As with most developments tasks that are worth doing (this one certainly is), there are numerous hoops that must be jumped through, most of which are documented in the Microsoft articles below. Note that bar editing a few XML statements so as to account for SharePoint virtualising its URLs (a lot simpler than it sounds - just follow the instructions), there is no need to get your hands dirty with serialization or SOAP (that's impossible with soap anyway, right?)

http://msdn.microsoft.com/en-us/library/ms464040.aspx (MOSS)

http://msdn.microsoft.com/en-us/library/ms464040(office.14).aspx (SP2010)

OK, so Web services that operate in the context of SharePoint foundation are not new. There are numerous tutorials available online that are very helpful such as Creating a Custom Web Service for SharePoint.

However, having spent a few frustrating hours with a number of recurring Web service issues, I thought it would be worthwhile sharing them with the world (or at least those that read this blog). If you are having issues deploying or consuming a custom Web service, I recommend you ask yourself the following questions:

Ask yourself

Have you created ASPX pages for the .disco and .wsdl files with syntactically correct virtualised URLs?
Is the updated Web service DLL in each SharePoint WFE GAC?
If relevant, is the updated Web service DDL in your SharePoint Web application bin folder with correct NTFS permissions?
Are the new DISCO, WSDL and ASMX files in the ISAPI folder with correct NTFS permissions?
Can you browse the web service at https://application.domain.com/_vti_bin/webservicename.asmx?
Does the Web service work as a console application?
Are your custom application settings (e.g. web.config) settings correct?
Is the problem really because of your Web service?

Note that although these common issues are based on my experiences with MOSS, I have taken a quick look through the 2010 walkthrough and there doesn't appear to be a lot of difference between the two processes. Please let me know if you have encountered a "common issue" that I haven't listed (MOSS or SP2010).

Good luck! I hope you enjoy consuming your new custom SharePoint Web service and the benefits that go with it. That includes code re-use, versatility and interoperability which hopefully leads to some form of cost saving for you and your organisation.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Administration: do you know your DR process?

noreply@blogger.com (Benjamin Athawes) — Thu, 22 Oct 2009 00:31:00 +0000

"This computer can't connect to the remote computer" is a verbose error message that us server administrators dread seeing when we connect to a server farm via RDP. A typical reaction would be to blame the local Internet connection (which in my case is a certain privatised former state telecommunications operator that will remain anonymous). Most of the time, we will try to access a site that is known to be "reliable" to confirm this is the case - I normally use Gmail. However, what would YOU do if Gmail was accessible and your server(s) wasn't?

As I have an unusually busy weekend ahead of me I thought I would quickly share with you a recent experience of mine and the various "what if" questions that sprang to mind.

It was a late night in the office and the sysadmin team was busy deploying the most recent batch of MS security patches to our farm. Notifications had been sent to our client base warning them of downtime so I wasn't too concerned when I witnessed the error above when I attempted to RDP to one of our ISA server boxes.

However, minutes quickly turned to an hour and the command prompt window I had opened to ping the server ("ping fqdn -t") was still returning timeouts. I knew something was amiss and, after confirming with the rest of the team it soon became obvious that the server in question had hung during a compulsory reboot following deployment of MS security patches.

A few queries crossed my mind at this point that made me realise that our DR process was more than a little ambiguous:

Ask yourself

What number would you use to contact your data centre? Where is it documented (and would it be available in a disaster...)?
When would you "sound the alarm" and notify other members of staff? Who would you escalate the issue to internally? What if they weren't available?
At what point would you notify clients of the service disruption?
What kind of authorisation would be required at the datacentre to approve a hard reset if this was necessary, and would the relevant individuals within your organisation be available?
Would you have available hardware resource to rebuild a server at a moments notice if necessary?
Are there any virtual environments available as a temporary resolution?
Are software and backups readily available to allow a new server to be rapidly provisioned?

As it happened, I was very lucky. In the absence of a clearly defined process, I decided to call our data centre right away to clarify what would be required to obtain access to the server farm if necessary. They informed me that a phone call to one of our "authorised contacts" would be sufficient for them to reboot the server themselves, which just so happened to resolve the issue.

I still haven't had a chance to identify the root cause of the issue, but the lessons that I learnt from this experience that I hope will be of use to you are as follows:

Ensure all contact details are thoroughly documented for both internal and external escalations. This includes the order in which contacts should be called and (ideally) a minimum of two phone numbers for each contact
Ensure escalation and notification times are clearly specified so remove ambiguity. In this context, a "gut feeling" probably isn't clear enough.
Ensure the correct process for obtaining appropriate security clearance is documented and that staff are made aware of said process.
Ensure sufficient resources (hardware, software, people) are available to deal with a crisis, especially where the nature of your service depends on high availability.

Ideally, all of this information should be documented already as part of a more general DR strategy but I would certainly recommend you ask yourself a few basic "what if" questions with regard to disaster and see if you are prepared.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Security: Preparing your SharePoint farm for a corporate security review (part 2 - Auditing)

noreply@blogger.com (Benjamin Athawes) — Tue, 20 Oct 2009 21:31:00 +0000

The words "security review" in the context of IT can mean different things to different organisations. For large organisations seeking to outsource an IT function to a third party hosting provider it could be simply a necessary formality; a series of hoops that must be jumped through in order to reassure users that the third party solution is secure. Secure in this context typically means that the risk of the service availability, integrity and confidentiality being impacted is no more than is usual for solutions of a similar nature.

However, for smaller organisations with fewer resources, it can sometimes result in a mixture of fear and anxiety due to the consequences of failing said review. After all, who would trust their sensitive data to a hosting provider that has not been found worthy of a security stamp of approval?

The concerns raised over a security review can be minimised by ensuring your organisation has prepared itself effectively. In preparing ourselves, we typically start by reviewing a list of "frequently asked queries" that most organisations send us as a part of their security review. This weeks category is Auditing (part one on Access Controls is available here):

Please note that the views expressed herein are my personal views and are not intended to reflect the views of my employer at the time of writing.

2. Auditing

Q. Will common actions (e.g. accessing and editing documents) be audited?
A. Clients like the ability to audit access to their information - ensure there is minimal impact to performance and enable it (IIS, SharePoint, Web Proxy logs).
This sounds like an obvious one but in my experience it is often missed when deploying SharePoint sites. MOSS itself has a number of different auditing options, and although to my knowledge there are no built in retention settings they do provide a fairly detailed means of auditing actions within SharePoint. A range of different events can be audited from basic actions such as opening documents to slightly more obscure events such as searching site content. I wont go into any detail here about how to go about configuring these settings in MOSS as Bill English has already provided a nice post on his blog.

I have heard rumours that SharePoint 2010 will include retention settings as well as the current settings provided by MOSS - please let me know if you know somewhere that confirms this.

Aside from SharePoint, I would also recommend you enable IIS logging (log to somewhere other than the OS drive to prevent unnecessary disk usage) and Web proxy logging (e.g. ISA Server) where applicable. In our case, we set ISA server to log to file rather than a SQL DB for consistency with the IIS logs.
Q. How, and how often are the log files checked?
A. Weekly is typically sufficient but this may need to be more frequent depending on the nature of your service. In particular, check SharePoint access and AD audit logs.
Manually checking logs for security breaches is a necessary (albeit dull) part of maintaining a secure hosted service. A diligent server administrator should implement a range of processes to minimise the chances of a security breach going unnoticed depending on the nature of the service offering. In the context of a SharePoint site, I would recommend that access logs (that is, SharePoint audit logs and IIS logs) are compared to your ACLs. For IIS, I would recommend you use a tool such as Log Parser; for SharePoint I would start with the built in site collection usage reports and analyse the more detailed audit reports on a less frequent (e.g. fortnightly) basis.

You should also consider checking your AD logs (Windows "Security" logs on your domain controllers) on a regular basis as a part of your audit process.
Q. Are server log files read only?
A. Set all log files to read only to improve log credibility. Consider moving old logs to another server to prevent tampering.
Setting log files to be read only is an essential step toward maintaining credible log files.

Obviously someone in the organisation must retain write access to the logs but this risk can be mitigated by implementing SoD and preventing those individuals from having write access to the relevant sites (as opposed to site logs) in question. In smaller organisations, it may be easier to simply grant write access only to a very small number of individuals - perhaps those in the upper echelons of management (I'll let you decide if that's a good idea).

Mark Burnett wrote a good post on this back in 2002 (here) that I recommend you refer to for a more detailed explanation.
Q. Are failure and success logon attempts logged?
A. Consider enabling failure and success auditing based on your disk space and log retention requirements.
This seems to be another common query. In preparing for a corporate security review I would recommend you review your current log space requirements and (if you haven't already) consider enabling both failure and success auditing. I mention disk space because enabling failure and success auditing can rapidly fill a log for a large site and may not be feasible where storage is limited. This risk is further increased by the chances of a DoS attack which would result in a large number of failure audits in quick succession (see this MS article for more information).

A workaround for this problem is to enable log overwrites and limit the size of the event log based on current size and log retention requirements. For financial systems (e.g. banks) this option is typically not viable given that there are typically legal requirements to retain logs for a fixed duration of time. However, for Web applications that are of a less sensitive nature (that are not subject to the same legal restrictions) you may want to consider this as an option.
Q. Are logs backed up?
A. Ensure all logs are backed up and secured in a separate location to your Web server(s).
Again, this is something I typically get asked by financial organisations due to their understandably stringent security requirements. Whether your clients have asked for this or not, however, I would recommend you implement a log backup process that meets your retention requirements. If logging to a file (e.g. IIS), this can easily be achieved by adding the log directory to your regular NTBackup routine.

When backing up logs, ensure that the logs are shipped to a location that is physically separate from your Web servers. This is useful from both a log integrity and DR perspective - if a security breach occurs on your Web server and there is a risk that the logs have somehow been tampered with (have you set them to be read only?), you have a second copy for verification. If your Web servers suffer a hardware failure, you still have log backups to meet any legal requirements that may be imposed on your service.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Administration: Find the needle in your (MOSS) event log haystack

noreply@blogger.com (Benjamin Athawes) — Thu, 15 Oct 2009 20:00:00 +0000

Those that follow my blog may be expecting this post to be part 2 of my corporate security review series (part one is here). However, I figured I would save that post for next week and instead share something that I use on a regular basis whilst looking after our MOSS farm. I hope it's of use to you.

As a MOSS Server farm administrator, we get used to seeing a fair few common event IDs in Windows server event logs. Most of them are simply "informational" messages, but it's also common to see numerous warnings and errors. The challenge is knowing which events are a threat to your SharePoint installation and which ones are safe to ignore. As diligent server administrators we strive to remove each and every warning from the event log but in reality this can be a very difficult task in all but the smallest of farms.

To record common events, I keep a log handy (no prizes for guessing that it takes the form of an Excel spreadsheet stored within a SharePoint document library). I have included the most common issues contained in this list below. Note that although I have compiled this list based on my own experiences and research (read "googling"), I can't guarantee that the resolution will work for you as every SharePoint installation is different.

Please take a look and let me know if any of these look familiar:

Common MOSS related Windows Event IDs:

6398, 7076 and 6482 (Errors): "Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
Hay: No direct issues to my knowledge but 3 errors at once is an eyesore in your Windows event log. Apply the hotfix.

These three errors tends to show up together every hour or so and can certainly look rather worrying in the Windows event log. In my experience I haven't noticed a problem that has occurred directly as a result of this issue (supposedly a compatibility issue between a .NET 2.0 remoting application and Windows Server 2003 SP2), but I would certainly recommend downloading and installing the MS hotfix contained in the link below.

Permanent resolution: http://support.microsoft.com/kb/923028

Temporary resolution: restart restart the "Windows SharePoint Services Administration" & "Windows SharePoint Services Timer" services.

6875 (Error): "Error loading and running event receiver
Microsoft.SharePoint.Publishing.Internal.ScheduledItemEventReceiver in
Microsoft.SharePoint.Publishing"
Hay: An informational error message (thanks Microsoft) - safe to ignore until you deploy MOSS SP2 which includes the hotfix.

This used to appear for us whenever we published a page in SharePoint when major versioning was turned on (which I believe is turned on by default within a publishing portal). As you might expect, the error cropped up a lot. The good news is that it is safe to ignore as the message is, according to MS an "informational" error. The best news? The hotfix is contained with MOSS SP2 so the error should disappear once you get around to deploying the service pack.

Permanent resolution: http://support.microsoft.com/kb/948323

7078 (Warning): "Job 'User Profile Incremental Import Job' failed. It will be re-tried again in 240 second(s). "
Hay: Due to SharePoint starting multiple jobs at once - check your timer job definitions in Central Administration for conflicts but otherwise safe to ignore.

This one occurs for us approximately once per week at varying times and in my opinion is safe to ignore (after all, the warning does state that the job will rerun). There doesn't appear to be a documented resolution from Microsoft thus far.

Explanation: http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/5353c169-c713-40d0-972c-fd24a1d64184/

2436 (Warning): "The start address cannot be crawled "
Needle:Typically due to incorrectly defined start addresses - check Central Administration.

For us, this was simply a case of human error and was very straightforward to correct within Central Administration > > Content Sources > Edit Content Source. In our case, we ensured that our start addresses matched the default URL's defined within "Alternate Access Mappings".

1113 (Error): "One of the IP/Port combinations for site 'ID' has already be configured to be used by another site. The other site's SSL configuration will be used. "
Hay, so long as your IIS sites are up and running: A bug introduced by a new feature in Windows Server 2003 - safe to ignore.

If you host multiple Web sites on the same IP address and use host headers to differentiate your sites in IIS 6.0 (common for SharePoint installations), you may find (if using Windows Server 2003) that this error appears in your log whenever you perform an IIS reset. From what I gather, this is because prior to SP1, server 2003 could not handle host headers over SSL as host headers are encrypted and IIS had a hard job knowing which site to redirect the encrypted request to (a good example of the "chicken and egg" problem). Thankfully, the smart people over at Microsoft provided support for "wildcard" SSL certificates in SP1 but forgot to remove the error message above. I do not know of a way of removing the error but I am confident that this should not be a problem for you so long as your IIS is configured correctly.

Note that in cases where your IIS 6.0 installation is not configured correctly, you will certainly know about it if the problem is related to SSL bindings as your Web sites will effectively become unavailable, especially if publishing SharePoint via a secure proxy such as ISA Server 2006.

Explanation: http://paldev.net/blogs/hafanah/archive/2009/08/17/hosting-multiple-websites-applications-on-iis-part-1.aspx

1310 (Warning): "A configuration error has occured: duplicate "System.Web.extension" tags"
Needle: Remove the duplicate web.config tags.

This used to occur for us a regular basis whilst deploying SharePoint Web applications. I never quite put my finger one what caused this problem but the fix was as simple as removing the offending duplicate tags from the applications web.config file. In the case above, SharePoint duplicated the "System.Web.Extensions" tags rendering the site inaccessible.

That concludes today's post. Let me know if you find any "needles" in your MOSS event log haystack that I haven't covered.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Security: Preparing your MOSS farm for a corporate security review (part 1 of 3)

noreply@blogger.com (Benjamin Athawes) — Tue, 13 Oct 2009 18:31:00 +0000

I would like to begin this post by thanking those that have recently subscribed to this blog via RSS. I always have a hard time deciding whether a blog should consume valuable space within my Google RSS reader so greatly appreciate the thought.

This post is primarily intended for those hosting or planning to host secure MOSS Web applications, although most of these points could also be applied to most Web applications that host sensitive content over the security minefield that is the Internet.

Having recently been through numerous corporate security reviews with potential clients, I thought it would be interesting to share some of the common queries that I get asked, along with an explanation and indication as to what constitutes an "acceptable" answer in terms of security. I imagine a lot of MOSS system administrators that host secure, Internet facing Web applications have been through the numerous security related hoops described below (including, in most cases a "PenTest" - I will detail preparation for that in another post). I thought it would be useful to document some of the most common queries.

Please note that the views expressed herein are my personal views and are not intended to reflect the views of my employer at the time of writing.

Without further ado:

1. Access Controls
Q: How many different access levels are there for your application?
A: 2 levels of access control is normally sufficient.
This one depends on the nature of your application. In most cases, an externally accessible MOSS Web application will contain multiple access levels. Similarly, in cases where said MOSS Web application is third party hosted, clients may not have access to carry out potentially dangerous functions that only an "administrator" should be able to perform. Typically, most users will have either "read" or "contribute" access, whereas power users might have "design", or even "full control" for some sites.

Security conscious organisations look for multiple access levels to allow for SoD. In my limited experience, the larger the organisation, the tighter the desired level of access control and, in MOSS terms the more users with "read" access. Having two clearly defined access levels is normally sufficient to satisfy most clients requirements but expect to implement more if your client(s) wish to implement access controls similar to their own organisational structure.
Q: Are users configured with individual usernames and passwords?
A: A must have for secure sites with auditing.
Pretty simple - in a secure environment where auditing is required, individual logons are a necessity rather than a luxury and your clients should demand it.
Q: Is a password policy enforced, including forced password changes?
A: Enforce a strong password policy; forced password changes are recommended.
We are forever told that choosing a secure password is a must when using sensitive applications - especially those hosted over the Internet. However, we as users can't be relied upon to resist entering a password any more secure than "chocolate123" or "admin1982". This seems to be a pet hate of large corporations, and rightly so. Enforce a secure password policy - at a minimum add some page level validation; preferably force the complexity requirement within your directory structure (e.g. Active Directory).

Security conscious organisations often look for forced password changes. However, it is not always required and this requirement does depend on the sensitivity of the application along any mitigating factors (e.g. a strong password policy and account lockouts, see below). In my experience, it is not essential.
Q: Does the application support account lockouts?
A: Enforce account lockouts with a realistic threshold
Automated account lockouts represent a basic, but effective measure against brute force attacks and a mitigating factor where password changes are not forced. I would go as far to say that it is an essential feature for applications that contain sensitive data - and so will your clients.

With regard to the threshold, many organisations will try to stick with their own internal account lockout policy. Commonly requested thresholds based on my experience are between 3 and 5, so I would recommend aiming for something around that area. For applications that do not require such a strict threshold, you may consider increasing this to a number between 6 and 10. This still provides some protection against brute force attacks whilst removing any frustration users might have over account lockouts.
Q: Is there a documented process for revocation of a users access?
A: Provide a clear, documented process that minimises chance of human error
In a lot of cases, I find that procedures for providing access are clearly defined and documented. Staff know exactly what is required in order to grant a new user access to a secure site. However, this is not always the case when it comes to revoking a users access, and is often left unchecked. If a user can't log in, your support staff will know about it soon enough. If they can log in after their account has "expired", you may find that you aren't ever notified there is an issue.

Reassure clients that you have a clear process and implement it. If you receive notification that a users access should be revoked by a set date, enforce account expiration in your directory structure and add a suitable description. In MOSS, you could go one step further and create a list of accounts marked for revocation.

Thats all for today. Join me soon for part 2. Still to come: Auditing, Change Management, Data Protection, Disaster Recovery, Infrastructure and Physical Security.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Administration: Migrating to a new SQL Server in MOSS (SQL 2005 to 2008)

noreply@blogger.com (Benjamin Athawes) — Sun, 11 Oct 2009 13:19:00 +0000

1. Overview

In this post I will describe the steps I took to successfully migrate from a SQL 2005 server to a brand new SQL 2008 server within a medium size production MOSS farm serving around 2000 users. The process makes use of the Microsoft supported method of migrating to a new DB server: SQL connection aliases.

As always, I strongly recommend you follow the steps below in a test environment prior to carrying them out in a live farm.

2. Scenario

Prior to the migration, we had a medium sized MOSS farm consisting of the following physical servers:

1 x86 SQL 2005 server running Windows Server 2003 SP2

1 MOSS application server hosting the MOSS Central Administration Web site and the query / index roles.

1 MOSS WFE server also hosting a MOSS Central Administration Web site for redundancy.

We host around 50 Web applications, each with their own content database.

The SQL 2005 server was very short on disk space (less than 20%) and, having considered a number of options including upgrading the disk capacity we decided that the simplest and safest (read "least risky") approach would be to purchase a new high capacity server and repurpose the existing SQL server (e.g. use it as an additional WFE server for redundnancy and performance).

We also decided that rather than install x86 Server 2003 and SQL Server 2005 on the new server, we would "future proof" the SQL back end by upgrading to x64 Server 2008 and SQL Server 2008.

As we would be repurposing the existing SQL server, we decided to go with the "Move all databases" approach documtned by Microsoft in this article: http://technet.microsoft.com/en-us/library/cc512725.aspx#Section1.

3. Gotchas

There are a few "gotchas" that I recommend you consider when planning to move to a new SQL server:

There is no supported method of changing the name of the server that the MOSS Admin Content DB resides on. Instead, the documented MS resolution is to use SQL aliases to point MOSS WFE servers to the new SQL server (which in my experience seems to be very effective, but feels like a bit of a hack).
The process for backing up and restoring MOSS SSPs is different to that used to move content databases.
The entire farm must be stopped prior to moving any databases to prevent any synchronsiation issues. In my case downtime was around 3 hours.
The SSP backup may fail if you have renamed any of your Web applications (see below).

With regard to the last issue, the error message I received when attempting to backup the SSP as a part of the migration was as follows: "Object Shared Search Index failed in event OnPrepareBackup." This is documented here: http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/9087ae96-c730-4b9f-85a4-67b4a4d67e65

The steps I took to resolve the SSP backup issue are contained in the appendix of this post, and are only relevenat if the SSP backup fails for you with the same error message.

4.1 High level steps

Backup all databases (including MOSS content and configuration databases)
Backup IIS on all WFE servers
Ensure integrity & dates of NTBackup file system backups on MOSS WFE servers (e.g. 12 hive, IIS directories)
Follow DB migration process outlined below
Stop SQL services on original DB server to ensure migration success
Test all portals
Add Backup & maintenance routines to SQL server
Modify any network or off-site backup routines your organisation may have to include the new server.

4.2 Detailed DB migration steps

Note that the steps below are basically a concise version of those contained at
http://technet.microsoft.com/en-us/library/cc512725.aspx with my own notes added in blue that I took whilst following them:

Follow http://technet.microsoft.com/en-us/library/cc263187.aspx to prepare the new DB server.
Record which Web applications are associated with the SSP
Back up an SSP by performing the following steps:

On the drive on which SharePoint Products and Technologies is installed, change to the following directory:

%COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

If you do not already know which node you want to back up, type the following command:

stsadm -o backup -showtree

In our case the SSP name was "SharedServices". Note that the UNC directory must be a shared drive accessible to both the WFE and DB servers as opposed to a local path on the WFE server.
Back up each SSP by typing the following command:

stsadm -o backup -directory -backupmethod full -item

Ensure the shared drive ("UNC Path") is available to the SQL server - i.e. in the format (\\server name\folder name) as opposed to a directory local to the server. This should complete with 0 warnings and 0 errors. The account used to perform this action must have access to backup databases on the database server (e.g. domain Administrator account).
After backing up, remove each SSP by following these steps:

On the disk on which Microsoft SharePoint Products and Technologies is installed, change to the following directory:

%COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

To remove an SSP, use the following command:

stsadm -o deletessp -title -deletedatabases -force

I believe that removing the content DB in central administration has the same effect.
If using STSADM, check the content database name for the SSP Web application in central administration. In our case the SSP contentdb name was "WSS_Content_".
Delete each SSP content databases in SQL Management Studio.
Stop the farm by stopping all SharePoint services on all WFE servers (documented in MS article referenced above). Then, on each server that is running the Central Administration Web site, at the command prompt, type iisreset /stop.
Back up all databases on the existing (old) database server. I performed a full backup of all "User" databases, then copied them to a separate server within the farm for safety.
In Windows Explorer, locate the database backup (.bak) files that you want to move, and then copy or move them to the destination server.
Important: Move only the backup files to the destination database server. Do not move any databases or other files at this time.
Restore all databases on the destination database server.
use http://support.microsoft.com/kb/918992/ to copy all SQL Server logins using a couple of stored procedures.
Refer the farm to the new database server by creating a SQL Server connection alias.
Add aliases for both the FQDN and hostname.e.g. add hostname and hostname.domain.com. Perform this step on all MOSS servers in the farm.
Start the farm by starting all SharePoint services on all WFE servers (documented in MS article referenced above). Then, on each server that is running the Central Administration Web site, at the command prompt, type iisreset /start.
Obtain the GUID of each successful SSP backup:

stsadm -o backuphistory -directory
Restore each SSP to the new location:

stsadm -o restore -directory -restoremethod new -backupid -newdatabaseserver

Again, Ensure the shared drive ("UNC Path") is available to the new SQL server - i.e. in the format (\\server name\folder name) as opposed to a directory local to the server. This process took around 10 minutes to complete. This should complete with 0 warnings and 0 errors. Note that this process can be rolled back (by deleting the restored SSP) using:

stsadm -o deletessp -title -deletedatabases -force
Remove backup SSP directories.

5. Summary

In this post, we took a look at the process for migrating all databases from a SQL 2005 x86 server to a SQL 2008 x64 server. In future posts, I may go into more detail around the specification of the new server including decisions about the hardware choices and RAID configuration. Please post a comment if this post helped you!

6. Appendix: How to resolve SSP backup error "Object Shared Search Index failed in event OnPrepareBackup."

This is only appicable if you receive the error above when trying to backup a SSP. Note that this takes a LONG time if the SSP backup fails for multiple Web applications - you may decide to simply recreate the SSP rather than carry out this process but I chose this option as it seems to me like the least risky choice. In my case, this process took 10 hours for 23 Web applications but this time will vary depending on your experience with MOSS and number of Web parts you have.

Document the following MOSS Central Administration settings for each Web application that needs to be recreated to allow an SSP backup to succeed: "Policy for web application", "authentication providers", "Web application general settings" (timezone) settings, which Web parts that are deployed to which Web application, any people picker settings that need to be restored using STSADM.
Take the farm offline - in my case I simply created a rule to block all connections using ISA server 2006.
Backup IIS for all WFE servers.
Backup all MOSS DBs including content and configuration databases (you never know...).
Delete the Web application in SharePoint that failed to backup - do NOT delete the IIS Web site or content DB.
Ensure you have a full backup of the IIS Web site content - I used NTBackup. In particular, ensure you have a backup of the Web.config file as SharePoint overwrites this when you recreate the Web app.
Delete IIS Web site
Create new Web application with new IIS site & note down default (temporary ) content DB name (to be deleted)
IISreset /noforce
Remove temporary content db in MOSS Central Administration
Delete temporary content DB in SQL Server Management Studio.
Reattach correct content DB and confirm no. sites > 0- restore web.config from NTBackup-
Repeat the above for all sites that are reported when attempting to backup the SSP.
Backup IIS on all WFE servers again in case a manual virtual directory restore is required
Restore IIS backup on all WFE servers
Reconfigure the "Policy for web application", "authentication providers" and "Web application general settings" (timezone) settings for each restored Web application in MOSS central administration.
Redeploy web parts to all restored web applications
People picker settings for all restored web applications using STSADM.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

ISA Server: Publishing MOSS with ISA Server 2006 SP1: Lessons Learnt

noreply@blogger.com (Benjamin Athawes) — Mon, 15 Dec 2008 20:05:00 +0000

Note: a version of this article updated for SharePoint 2010 is available on my new blog site here.

1. Introduction

Hi! This is officially my first blog post, not only in this particular blog but ever. I would provide an introduction, but I am almost certain that most of you are only looking at this as a result of a Google search for "publishing MOSS using ISA server 2006" (or something along those lines). Guilty? I thought so.

As such, I will skip the intro and get down to business. Following are some notes that I made whilst attempting to (and eventually successfully) configuring ISA Server 2006 to publish a series of MOSS portals. Although I could go into detail on how I carried out each step, I have decided to give an overview to begin with and respond to any requests the general public may have ("Could you show me how to get SSL bridging to work?" etc).

2. Acknowledgements

To start with, I must give due credit to those articles which helped me most whilst setting up ISA Server 2006 to publish a secure MOSS environment. Obviously you can find these for yourself using a search engine, but I thought it useful to show a concise list of those I found most informative:

Technet: Remote Management Concepts in ISA Server 2006 (Microsoft discuss best practises and precautions to take whilst remotely managing ISA server - read this one before installing if possible).
Technet: Publishing SharePoint 2007 using ISA Server 2006 (Microsoft's own article on publishing MOSS using ISA server - very useful to get started).
Technet: Plan alternate access mappings (From the Microsoft SharePoint team blog- includes information on configuring AAM using ISA server. Invaluable if you are looking at the AAM screen in SharePoint central admin and wondering why MOSS isn't working as you might expect).
Technet: Authentication in ISA Server 2006 (useful for understand how different authentication mechanisms operate in ISA server 2006).
MSFirewall.org.uk: Customising ISA Server 2006 HTML forms (I haven't actually used this one myself as it was only recently published but based on the fact that I have successfully configured custom login form branding myself I would say this article looks exceptionally useful).

3. Lessons Learnt

Most of us have heard the saying Keep It Simple Stupid (KISS). In configuring ISA Server, and particularly whilst attempting to configure SSL termination (so as to forward HTTP requests to the published MOSS Server), I realised KISS is probably the most concise way of summarising the lessons I learnt:

3.1 Proceed with care when installing ISA server remotely *Important!*

In case you didn't know, ISA Server is designed to function as an industry grade firewall. This means that unless you have configured it correctly, it will try its hardest to stop anything and everything from accessing it and the published servers it is protecting. This means you are locked out if the server is not configured to allow remote administration. I learnt this the hard way and had to drive to our MOSS farm to manually correct the issue - make sure you don't make the same mistake.

The key to preventing yourself from being locked out is to:

Before installation: add exceptions for RDP and file / printer sharing in the Windows Firewall prior to installation.
After installation: define "Remote Management Computer Sets". This means adding your IP address to the list of trusted remote management addresses. More detail on this can be found in the Technet article listed in the "acknowledgements" section of this post.

3.2 Install ISA Server 2006 SP1 from the beginning

I know - this sounds like an obvious one. But if you are as keen to get ISA server up and running as soon as possible you may be tempted to skip the updates. Don't do it. ISA Server 2006 SP1 includes a host of new features, but the most useful one has to be the ability to test a new publishing rule (you will see what I mean if you haven't yet installed SP1 and are having difficulty troubleshooting a given publishing rule).

3.3 Ensure AAM is configured correctly

This is, from what I have gathered the number one mistake made when troubleshooting ISA / MOSS publishing scenarios, particularly when using SSL termination (see the lesson below). Ensure you read and follow the Microsoft article on planning AAM in the "acknowledgements" section above. From my experience, I can say with great certainty that most issues you will encounter (particularly with regard to SharePoint document library functionality) will be related to an incorrect AAM configuration.

3.4 Use SSL bridging where possible

I spent a significant amount of time and effort attempting to get SSL termination (or off-box termination as it is commonly known) working due to my belief that SSL bridging would result in significant processing overhead. Before you make the same mistake, try SSL bridging for yourself in your own environment. In most cases, you will find the overhead is negligible and it could potentially save you a lot of wasted hours / hassle for the following two reasons:

SSL termination means the forwarded URL will contain HTTP rather than HTTPS. You will find that in most cases (assuming AAM is configured correctly), SharePoint will work just fine in this configuration. However, in my case I kept finding small niggling issues that required a fix (note that this is particularly the case if you use custom web parts that may store URLs in a database). An example of a problem with standard MOSS functionality was trying to export to a spreadsheet from a SharePoint list (if you think you have got SSL termination working correctly, try this for yourself to make sure).
SSL termination means that the channel from your ISA box to your MOSS farm is not secure. There are mixed opinions on whether this is a real security issue, but suffice to say I prefer to be able to (honestly) tell clients that "128 bit encryption is used end-end over a secure SSL channel". Sure, you may pass penetration testing and clients may not ever find out if you are using SSL termination, but there is always "what if".

3.5 Authenticate at the ISA server

Again, this sounds obvious. ISA server provides a perimeter defence mechanism and one of its main benefits is the capability to prevent unauthorised traffic from ever reaching your web servers. To be more specific, do not select "All Users" from within the users tab of any given publishing rule unless you really want anonymous users to access your MOSS site. OK - IIS will still prompt for authentication, but if you want to save bandwidth and CPU cycles, ensure "All authenticated users" is selected.

If, like me you have an environment where you want some areas of your MOSS site to be accessible anonymously (i.e. no authentication), I recommend you create a separate "Public" publishing rule. Ensure you define only those paths (in the "Paths" tab of the ISA Server publishing rule) you wish to be accessible by Joe Public.

By specifying that only "Authenticated users" can access your MOSS servers, you are effectively telling ISA server to communicate to your authentication provider (in my case AD) directly. Valid credentials are then forwarded (delegated) to your published web server.

3.6 Use ISA server monitoring functionality

This one has been almost essential for me. ISA Server 2006 SP1 includes numerous monitoring features, but by far the most useful for me was the "Logging" tab. This tab shows all requests passing in and out of the ISA server and is invaluable when troubleshooting a connectivity issue. Having problems updating Windows? In all likelihood ISA server is blocking HTTP access to the outside world. Not able to ping the ISA server even from within your farm? It's likely you haven't added those servers to the "Remote Management" computer set. Whatever the problem, it is likely that ISA Server's real-time logging capability will assist you.

3.7 Utilise the Windows "hosts" file

As I'm sure many server administrators will know, the hosts file is a valuable tool for forcing a computer to ignore DNS for a particular hostname and use a manually configured IP address. It can be handy to test the ISA server is forwarding requests to your published MOSS server correctly without having to modify the public A-record right away. The file itself is located in C:\Windows\System32\drivers\etc - I normally modify it using notepad.

4. Conclusion

In this post we took a look at some of the lessons I personally learnt whilst publishing MOSS using ISA server 2006 in a real world environment. Depending on whether I receive any comments I will most likely publish future blog posts. If you found the post useful, have a question or have a constructive criticism please let me know! I will in the future be posting about all things MOSS related (not just ISA server) so please subscribe if you are interested.

Cheers, Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites