[SP ALL] Opening a web service is returning a 401.1 "Access Denied" error

[ISSUE]
Yesterday I was asked to assist in troubleshooting an issue with a SharePoint web service. The SharePoint indexing process failed to work properly for just one web application. Some investigation revealed that the indexer was unable to open the sitedata.asmx web service. When trying to open the same web service via IE, I was prompted for credentials however whatever credentials were entered, after three attempts an "Access Denied" page (401.1 error) was shown.

[SOLUTION]
Unfortunately Process Monitor didn't reveal anything and I noticed that the sitedata web service wasn't the only web service that failed. After some troubleshooting I found out that the cause was in the web config:

The "remove verb *.asmx" line was placed after the "add verb *.asmx" line in the httphandler setting, essentially removing the configuration after adding it. For example:

<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
....
<remove verb="*" path="*.asmx" />

After correcting this by placing the remove line in front of the add line, all web services started working just fine!

<remove verb="*" path="*.asmx" />
....
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

[EXPLANATION]
Why is this happening? By first placing the remove line, you make sure any declarations that are done in other (global) configuration files are made void. That way you know for sure that no conflicts will occur between two configurations. However after removing the asmx httphandler, you have to declare it again, else SharePoint (or better yet IIS) does not know how to handle the asmx file. The confusing part for this issue is that it will display an authentication prompt to the user, without it actually being an authentication issue.

[MOSS2007/WSSv3] SharePoint 2007 Build numbers (Updated)

Here a list of build numbers for SharePoint 2007. This list is updated until the December '11 Cumulative Update:

12.0.6656 - MOSS2007/WSSv3 December '11 Cumulative Update
12.0.6654 - MOSS2007/WSSv3 October '11 Cumulative Update
12.0.6608 - MOSS2007/WSSv3 Service Pack 3
12.0.6565 - MOSS2007/WSSv3 August '11 Cumulative Update
12.0.6562 - MOSS2007/WSSv3 June '11 Cumulative Update
12.0.6557 - MOSS2007/WSSv3 April '11 Cumulative Update
12.0.6554 - MOSS2007/WSSv3 February '11 Cumulative Update
12.0.6550 - MOSS2007/WSSv3 December '10 Cumulative Update
12.0.6548 - MOSS2007/WSSv3 October '10 Cumulative Update
12.0.6545 - MOSS2007/WSSv3 August '10 Cumulative Update
12.0.6539 - MOSS2007/WSSv3 June '10 Cumulative Update
12.0.6535 - MOSS2007/WSSv3 April '10 Cumulative Update
12.0.6529 - MOSS2007/WSSv3 February '10 Cumulative Update
12.0.6524 - MOSS2007/WSSv3 December '09 Cumulative Update
12.0.6520 - MOSS2007/WSSv3 October '09 Cumulative Update
12.0.6514.5004 - (Corrected) MOSS2007/WSSv3 August '09 Cumulative Update
12.0.6514.5000 - MOSS2007/WSSv3 August '09 Cumulative Update
12.0.6510 - MOSS2007/WSSv3 June '09 Cumulative update
12.0.6504 - MOSS2007/WSSv3 April '09 Cumulative update
12.0.6421 - MOSS2007/WSSv3 SP2
12.0.6341 - MOSS2007/WSSv3 February '09 Cumulative update
12.0.6335 - MOSS2007/WSSv3 December '08 Cumulative update
12.0.6327 - MOSS2007/WSSv3 August '08 Cumulative update
12.0.6318 - MOSS2007/WSSv3 Infrastructure Update
12.0.6300 - MOSS2007/WSSv3 post-SP1 hotfix
12.0.6219 - MOSS2007/WSSv3 SP1
12.0.6039 - MOSS2007/WSSv3 October '07 public update
12.0.6036 - MOSS2007/WSSv3 August 24 '07 hotfix package
12.0.4518 - MOSS2007/WSSv3 RTM

You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

I use SharePoint

Released last week: I Use SharePoint

A lot of information (howto's, Quick Reference Cards, etc) on how to use SharePoint!

Two very good SharePoint articles

Yesterday I ran into two very good SharePoint articles, that describe an often forgotten part of a SharePoint implementation: Governance!

• We've installed SharePoint, we have a successful platform right? Wrong!
• SharePoint is a car

[SP2007/SP2010] Migrate SharePoint across domains

A while ago I worked on a project where we had to migrate a customer’s SharePoint 2007 environment from another service provider to a newly created environment in our own datacenter. The challenge we had during this project was that the new environment was built from scratch, meaning that the Active Directory would be a different one than the original environment was located in. Unfortunately there were no possibilities to create a trust between the two domains.

The above would mean that since the Active Directory changed, , the domain name would change as well as all user accounts (or SIDs). This meant that all security permissions, alerts and ownerships would become unusable. These had to be migrated to the new accounts in the new AD.

For migrating users, SharePoint offers a stsadm operation called “migrateuser”. However, at the time of the project there was no operation for groups migration, so we needed a solution for that as well.

[PROJECT INFO]

• The web application URL's would not change
• The user account format would not change in the new Active Directory. User1 in the old AD, would be User1 in the new AD.
• MIIS was used to create the users in the source environment. ILM2007 would be used in the new environment. Any custom code used in MIIS could be migrated to the ILM2007 environment, however some changes and updates would be made in the process.
• The old environment was based on 32 bit SharePoint 2007 on Windows Server 2003. The new environment would be based on 64 bit SharePoint 2007 on Windows Server 2008.

[ISSUES]

• The source SharePoint environment contained a SSP. Unfortunately there is no way to copy the SSP or its settings to the new environment automatically. The SSP had to be recreated manually.
• The user profiles in the SSP had to be migrated as well. There was no tool available that was able to export the user profiles and import in our new environment. We had to create a tool for this. On Codeplex we found a Profile Import tool (MOSS Profile Importer), but that was unable to export the information from an existing SharePoint farm. We used this code as a starting point for our own tool.
• The migrategroup command did not exist yet, fortunately only seven different AD groups were used. These needed to be migrated manually.
• The stsadm operation migrateuser has to be run for each user id. A custom solution is required to generate a script for all users. Running this script consumes much time and needs to be shortened as much as possible.

[MIGRATION]
The preparation steps we took were:

• Create the custom tooling require to perform the migration (profile export/import, migrateuser script)
  
• Perform a test migration in order to validate the migration steps and target environments.
  

The steps we took to migrate the content were:
Environment setup

• Setup the new SharePoint 2007 environment and use same patch level as the original farm
• Install all custom solutions on the target environment
• Create all users in the new Active Directory
• Setup the SSP in the target environment and configure it according to the settings of the old environment (user profile properties, profile import, audiences, search, etc)

User profile information

• Import all users from AD into the SSP
• Backup all user profile information to file
• The import tool is using the user id to import the data to the correct profile, so we had to replace the old domain name with the new domain name in the export file
• Restore all user profile information into the new SSP

Content

• Create SQL backup of the source content databases (web applications and MySites) to a USB disk
• Ship the disk to the other datacenter and connect it to the server
• Restore the SQL backups on the target SQL server from USB disk
• Connect the content databases to the correct web applications
• Test the site collections for correct operation of the databases
• Run the migrateuser script generation tool. This tool created three script files, which we could run on three different servers to speed up the migration process.
• Run the migration scripts
• Manually change group membership for each used group (add new group, grant permissions and remove old group) in the entire site structure

Testing

• Test, test, test

[POST INFO]

• Since the August 2009 Cumulative Update, SharePoint 2007 stsadm includes the migrategroup operation, which is able to migrate groups the same way migrateuser does for users.

[MOSS2007/WSSv3] PowerShell Library - List where a feature is activated

[DESCRIPTION]
Microsoft recommends to deactivate a feature everywhere before you remove the feature from the environment. Unfortunately there is no way of determining where the feature is activated.

To solve this issue, I have created a PowerShell script.

How to use it:

1. Download the PowerShell script
2. Open the script in Notepad and edit the <featureid> text to match the id of the feature you are interested in
3. Run the script
4. Open the output in Microsoft Excel and use "*" as separator
5. Based on the Scope column you can determine if the specific feature is a site or web feature

The “Soft” part of SharePoint - Part 6, Challenge the Business

This is a tricky one! I know the saying "the customer is always right" or "the customer is king". In IT the business is your customer, IT by itself is useless. IT is there to support the business to work as efficient as possible, but does this mean that the customer is indeed always right.......

I have seen many cases where IT puts the business before everything. They do pretty much everything to do what the business asks them to do, often without questions. Very often this resulted in projects turning into disasters:

• The business asks for more that they need
• They radically change their requirements when you just started the implementation

And of course, afterwards the business starts complaining that it took too long and the costs were too high.

Then what is causing these kind of issues. Two reasons behind these drama’s are:

1. The business doesn’t know what exactly they want.
• Result 1: They ask something else every day
• Result 2: They ask what they think they want
2. The business is asking for IT solutions instead of specifying the business need
• Result: They ask for a technical solution which is not fitting their business need

That is why IT should challenge everything the business is asking for: Do they have a clear picture what they want? Do they really want what they ask? Don't they mean something else and therefore ask the wrong question? Isn’t there an easier way to meet their business need?

This is not to question everything they do, but to get to know the true question behind the question. When all requirements are clear on all ends, projects can be executed easier and cheaper.

[MOSS2007/WSSv3] PowerShell Library - Check for large lists

[DESCRIPTION]
Microsoft recommends not to use lists/libraries with a huge amount of items, so called large lists. These lists can seriously impact the performance of SharePoint. Unfortunately there is no way to keep track of such large lists from an administrative side.

In order to be able to determine where large lists exist, I have created a PowerShell script.

How to use it:

1. Download the PowerShell script
2. Open it in a text editor like Notepad
3. Run the script
4. Open the output in Microsoft Excel and use "*" as separator

[MOSS2007/WSSv3] PowerShell Library - Overview Request Access Email Address

When creating a site collection or sub sites, it is possible to configure an e-mail address to which SharePoint will send Access Requests mails. When a mail address of a user is configured and that user leaves or changes roles, by default there is no way of checking where that address is used.

To solve this, I have created a script that generates a report with all configured mail addresses:

How to use it:

1. Download the PowerShell script
2. Run the script
3. Open the output in Microsoft Excel and use "*" as separator

The “Soft” part of SharePoint - Part 5, Change Management

This time something that is not really SharePoint related, but this doesn’t make it less important!

Way too many times I have seen “Administrators from the Wild West”, in other words true cowboys. Clicking links and buttons like their lives depended on it. Reading error messages is so 2010 :-)

When troubleshooting an issue, Google is my friend. However not all answers given on the Internet always work or are safe to the environment. What if something goes wrong and I bring down the environment……..in a lot of cases all hell will break loose and I have to test my running skills :-p

How to prevent this?
Every change you are about to implement to a production environment is supposed to be tested before implementation. If you are working as an administrator (server or application), I hope you are familiar with ITIL* and its procedures, especially change management. If not, see the “More info” section and read up real quick!!

In a lot of cases Change Management is seen as a pain in the butt. But when implemented correctly it can save you a lot of work or better yet save you from having to do some overtime. The goal of change management is to make you think well about the change you are going to implement and put those steps on paper:

• What are you trying to fix/resolve/accomplish?
• What changes are you going to make?
• What are the steps to implement the change?
• What are the components that are affected?
• What is the impact of the change for users and administrators?
• Who needs to be notified about the change?
• What to do if something goes wrong?
• What to document afterwards?
• Etc, etc

But that is not all: Two know more than one. Change management is also about having the thought process reviewed by others. These persons can have the same type of skills, but it is also important to have it reviewed by persons with different skills. Maybe your change has impact on their area of expertise you didn’t think of.

Change Management and DTAP
In combination with a DTAP strategy, Change Management can become even more powerful. All changes are tested on the Test environment, the implementation procedure tested on the Acceptance environment, after which the change is implemented on the Production environment.

More info:
ITIL: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
Change Management: http://en.wikipedia.org/wiki/Change_Management_(ITSM)

[MOSS2007/WSSv3] SharePoint 2007 Build numbers (Updated)

Here a list of build numbers for SharePoint 2007. This list is updated until the December '10 Cumulative Update:

12.0.0.6550 - MOSS2007/WSSv3 December '10 Cumulative Update
12.0.0.6548 - MOSS2007/WSSv3 October '10 Cumulative Update
12.0.0.6545 - MOSS2007/WSSv3 August '10 Cumulative Update
12.0.0.6539 - MOSS2007/WSSv3 June '10 Cumulative Update
12.0.0.6535 - MOSS2007/WSSv3 April '10 Cumulative Update
12.0.0.6529 - MOSS2007/WSSv3 February '10 Cumulative Update
12.0.0.6524 - MOSS2007/WSSv3 December '09 Cumulative Update
12.0.0.6520 - MOSS2007/WSSv3 October '09 Cumulative Update
12.0.0.6514.5004 - (Corrected) MOSS2007/WSSv3 August '09 Cumulative Update
12.0.0.6514.5000 - MOSS2007/WSSv3 August '09 Cumulative Update
12.0.0.6510 - MOSS2007/WSSv3 June '09 Cumulative update
12.0.0.6504 - MOSS2007/WSSv3 April '09 Cumulative update
12.0.0.6421 - MOSS2007/WSSv3 SP2
12.0.0.6341 - MOSS2007/WSSv3 February '09 Cumulative update
12.0.0.6335 - MOSS2007/WSSv3 December '08 Cumulative update
12.0.0.6327 - MOSS2007/WSSv3 August '08 Cumulative update
12.0.0.6318 - MOSS2007/WSSv3 Infrastructure Update
12.0.0.6300 - MOSS2007/WSSv3 post-SP1 hotfix
12.0.0.6219 - MOSS2007/WSSv3 SP1
12.0.0.6039 - MOSS2007/WSSv3 October '07 public update
12.0.0.6036 - MOSS2007/WSSv3 August 24 '07 hotfix package
12.0.0.4518 - MOSS2007/WSSv3 RTM

You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

[MOSS2007] PowerShell Library - Start Incremental crawl

[DESCRIPTION]
SharePoint 2007 does not support crawl schedules larger than 24 hours. So if you want to schedule a crawl to run every 36 hours, by default there is no way to do this.

At a customer we had a very large environment, which had a huge amount of changes on a daily bases. A crawl during the weekend took just a few minutes, but during the week this increased to 32 hours. Because Microsoft also recommends not to start a crawl when the previous crawl is still running (even though it cannot run two instances of the same crawl, SharePoint does something that can break the index before it detects the crawl is already running), I have created a script that does this for me.

The script checks if a crawl is running and if so quits. If a crawl is not running, it starts another incremental crawl. By scheduling this script every 15 minutes, I can make sure the crawl is never stopped for more than 15 minutes.

How to use the script:

1. Download the PowerShell script
2. (If necessary) Change the Content Source name
3. Run or schedule the script

[MOSS2007/WSSv3] PowerShell Library - Site definition inventory

For a project we were wondering which site definitions were used in our environment. I created the following script in order to create this inventory. It loops through all web applications, site collections and sub sites and logs the use definition for each site in a log file:

How to use it:

1. Download the PowerShell script
2. Run the script
3. Open the output in Microsoft Excel and use "*" as separator

[MOSS2007] PowerShell Library - Delete MOSS User Profiles

[Description]
At a customer we had some disabled accounts which were not imported in the profile database but did have an MOSS profile. For whatever reason SharePoint did not deleted these profiles. The customer wanted to delete these profiles without removing all profiles.

To achieve this goal, I have created a PowerShell script.
How to use it:

1. Download the PowerShell script
2. Open it in a text editor like Notepad
3. Change the <url> into the URL of the web application you would like to check
4. Run the script

[MOSS2007/WSSv3] PowerShell Library - Dump all solutions

Today I am sharing a PowerShell script I have created to export all solutions that have been added to SharePoint Solution Deployment.

A while ago I visited a customer to troubleshoot an issue, however they did very little about any form of documentation. This meant that I had no way of determining exactly which version of solutions they had installed. Using this PowerShell script I was able to export all installed solutions and start testing using the actually installed solutions.

How to use the script:

1. Download the PowerShell script
2. Create a folder called "Solutions" in the same directory
3. Run the script
4. All solutions (wsp files) are downloaded to the Solutions directory

[MOSS2007/WSSv3] PowerShell Library - Check for large Nintex workflow lists

Over the past months, I have been creating several PowerShell scripts in order to make my life a little easier. This week I thought, why not sharing these scripts with the world and make everybodies life a little easier :-)

Therefore here script number 1: Check for large Nintex workflow lists!

[DESCRIPTION]
When using Nintex Workflow 2007 and activating the site feature, a hidden list is created in that site called NintexWorkflowHistory. Even time a workflow starts, a Log History action is used, etc an entry is written in this log. Unfortunately this list is not cleaned automatically, potentially becoming a feared "Large List". On one occasion a user had created a workflow that added 200.000 items in just five days to that list. Because it is a hidden list, it does not appear in the GUI and you cannot easily see the size of these lists.

In order to be able to determine where large Nintex lists exist, I have created a PowerShell script.

How to use it:

1. Download the PowerShell script
2. Open it in a text editor like Notepad
3. Change the <url> into the URL of the web application you would like to check
4. Run the script
5. Open the output in Microsoft Excel and use "*" as separator

The script generates an output file in the following format:

http://examples.sharepoint.com/sites/NintexSite * 8927
http://examples.sharepoint.com/sites/NintexSite/SubSite * 5304
http://examples.sharepoint.com/sites/NintexSite2 * 3840
http://examples.sharepoint.com/sites/NintexSite2/SubSite * 10239

The “Soft” part of SharePoint - Part 4, DTAP

What is DTAP?
DTAP is a strategy very often used in software development projects. It stands for “Development, Test, Acceptance, Production” (http://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production). Software is developed on a development environment, then technically tested on the Test environment, user acceptance tests are performed on the acceptance environment after which it is transferred to the production environment.

SharePoint is a product that can function as a platform on which companies can build custom solutions. Even though SharePoint is build on the .NET Framework, it has its own rules and boundaries. Poorly developed code can easily affect SharePoint and cause it to fail or seriously impact performance. From an administration standpoint it is very important to evaluate solutions before deploying them to the production environment (see previous article in this series). A DTAP strategy will assist you in this evaluation process.

But not only with the deployment of solutions a DTAP strategy can be useful. Also the implementation of changes or SharePoint updates/Service Packs can benefit from this strategy. They can first be tested before implementing on the production environment.

Environments: Purpose and permissions
Development
With SharePoint you can have multiple kinds of development environments. Each developer can create his own virtual local environments or you can use a centrally managed environment. Both options have their pros and cons.

Local development environment:
Purpose: Environment used for developing new SharePoint solutions. The environment is under total control of the developer.
Responsible: Developer
Server admin: Developer
Admin access: Developer
Pro : Flexible, can be used everywhere, total control over environment, developers do not impact each other
Con : Developer has to maintain environment the environment (patches, etc), host needs to have sufficient resources, environment used by one developer only

Central development environment
Purpose: Environment used for developing new SharePoint solutions. Multiple developers per environment (2 max), but they can impact each other.
Responsible: Developer
Server admin: TAM
Admin access: TAM & Developer
Pro : Centrally managed according to standards, multiple developers per environment, requires less licenses, no high end local hardware required
Con : Can only be used when connected to the network (direct or VPN), developers can impact each other

Test
Purpose: Environment used for technical testing of developed SharePoint solutions (check if conflicts are present with other solutions) and their deployment instructions. Also changes to the environment (e.g. change of settings or implementation of patch or Service Pack) can be tested on this environment.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: FAM and developers have admin access to SharePoint site collections and if required read access to administration pages

Acceptance
Purpose: Environment used for functional testing of developed SharePoint solutions (check if solutions complies with functional design). This environment should match your PRD as close as possible (setup and configuration wise). Just content can be out-of-date.
Responsible: FAM
Server admin: TAM
Admin access: TAM
Other access: FAM has admin access to SharePoint site collections and if required read access to administration pages

Pre-Production environment
Purpose: Environment that is a very close mirror to the production environment. Mirror on solutions, content, architecture and infrastructure. Meant for testing the implementation to a production like environment and the impact on production. Performance tests can also be done on this environment.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: None

Production environment
Purpose: Environment that is running the production solutions/content and is serving end-user requests.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: FAM has admin access to SharePoint site collections and if required read access to administration pages

Important!!
Make sure that starting with the Test environment and onwards, all environments have the same layers of the topology. The environments don’t have to be equal in number of servers, but if PRD has three layers (database, application. Web front-end), Pre-Production, Acceptation and Test should be three layers as well. Back in 2006 I learned this the hard way (http://share-point.blogspot.com/2006/02/problems-with-search-functionality.html). Our Acceptation environment consisted out of two servers and Production out of three servers……..Installation of Windows 2003 SP1 worked just fine on Acceptation, it didn’t on Production and broke search. It took me two weeks to find out the issue and another two weeks to clean up the mess I created during troubleshooting :-)

Explanation:
Purpose : Describes the purpose of the environment.
Responsible : Who is functionally responsible for the environment.
Server admin : Who is the administrating party of the environment and has to make sure that the environment is patched, secure, backed up, etc.
Admin access : Who has administrative access to the server.
Other access : Which other access is granted to which parties.
TAM : Technical Application Management
FAM : Functional Application Management

The “Soft” part of SharePoint - Part 3, Solution intake process

Where developer should have a standard SharePoint Development process, which describes the development best practices in your environment, should every SharePoint administrator have a solution intake process.

Poorly implemented custom solutions can introduce security or performance risks, increase the cost of support, complicate deployment, and reduce productivity. Over the past years I have seen that developers do not always know how to develop good solutions for SharePoint. Even though SharePoint is build on .NET, developing for SharePoint is a totally different discipline than developing for .NET. More than often I have seen developers delivering code that was either seriously affecting the environment, not using the SharePoint deployment framework or very poorly documented.

In order to guarantee quality, it is very important to create a solution intake process. The process verifies if certain best practices have been followed and the solution is safe to deploy the environment:

• Create a code acceptance checklist for the developer to fill out.
• This checklist forces developer to sign off their solutions against a list of Best Practices.
• Check the code using SPDisposeCheck.
• This tool checks the custom code for memory leaks and proper use of disposable objects.
• Check deployment documentation.
• Check if the deployment documentation is correct and contains the required information.
• Check solution package
• Check if the solution package is created properly, using the Solution Deployment framework technologies.

If you want to have a good example of a solution intake process, Microsoft has released some documents for their SharePoint Online cloud service. Their intake process is really strict and requires the developer to design, document and test the solution before handing it over to Microsoft. They have published their process in the following documents:

• SharePoint Online Dedicated Custom Solution Policies and Process (October 2010)
• SharePoint Online Dedicated Custom Solution Developers Guide (October 2010)

More information:
Check list example: http://technet.microsoft.com/en-us/library/cc707802.aspx
SPDisposeCheck: http://code.msdn.microsoft.com/SPDisposeCheck
Using Disposable Object: http://msdn2.microsoft.com/en-us/library/aa973248.aspx

The “Soft” part of SharePoint - Part 2, Impact of design choices

During every SharePoint design phase, choices have to be made on exactly how to implement SharePoint and its components. These choice can have serious implications later on during the administration phase.

To be able to create a good design, it is imperative to have good requirements for the environment. These requirements must be gathered both at the business and at IT end, as they both have to “use” the platform in the future, although their use will be completely different.

For example:

1. Where the business has certain availability requirements (e.g. 99.9% 24x7), IT has the requirement that these availability requirements must be achieved using redundancy. The final design has to be an environment design with which all parties can live with.
2. In order to deliver a good service, IT will have to be able to test each change to the environment. In order to do this, they will require testing facilities in the form of DTAP environments. In most cases, the business will experience the DTAP strategy as annoying and time consuming.

It is very important that all choices are documented in a design document, especially when the persons performing the implementation are different than the actual administrators of the environment. The design document has to be reviewed and approved by the future administrators before implementation starts. If during implementation a deviation from the original design has to be implemented, this deviation has to be agreed between both parties.

Basically: If the implementation project messes up (for whatever reason), the future administrators will suffer the consequences!!

Very good examples of critical design choices with high impact are:

• Use of a DTAP environment* - During a project, implementing a DTAP strategy requires time and money. Two things a project very often doesn’t have a lot of. Skipping the implementation of DTA environments saves time and money for the project. However this choice will seriously impact administrators in their ability to test changes before implementation (patches/service packs, new solutions or configuration changes).
• Redundancy in the environment - Implementing redundancy requires extra hardware and therefore extra costs for hardware, software licenses and installation. If during implementation the requirements do not include redundancy, this will not be designed and implemented. Unfortunately, adding redundancy later will require a lot of work and has a high impact, especially for SQL Server where adding redundancy (clustering) will mean a complete reinstallation of the entire SQL environment.
• Sizing - I have been part of a project where the available storage was limited. We only had a certain amount of storage available, that was it. The disk space for all servers was just enough to contain all data. Once the environment was transferred to the administrators, one of the first things they had to do was adding extra disk space and moving database across these extra disks.

The message of this story: Most items mentioned might sound obvious, but unfortunately I have seen a lot of situations where this turned out to be harder than you would think/like.

If you are part of the implementation project, make sure that you involve the future administrators as soon as possible. If you are the future administrator, make sure you get involved as soon as possible. Each design decision has to be approved by both parties! So check and communicate between both parties early and continuously.

A very good input for IT requirements are acceptation criteria. This is a list of criteria to which the project has to comply to. That way you can save yourself a huge amount of time, effort and stress! So make sure you create these!

*More on DTAP will follow in a later post

The “Soft” part of SharePoint - Part 1: Skills

With products like Exchange, only IT Pros are involved, the people who are implementing or administering the environment are often the same people that are managing the Windows operating system. At least they have sufficient (infrastructure) knowledge to cover all bases.

With SharePoint, this is a whole different ball-game. As SharePoint is build on top of a lot of Microsoft infrastructure products, good infrastructure knowledge is very important (Windows, DNS, Active Directory, ISA Server/TMG, etc). Unfortunately more than often, SharePoint knowledge is very limited with people who are cracks in those technologies. SharePoint developers however have very limited infrastructure knowledge, so they have a hard time doing a very good job from a performance/security perspective. In other words implementing or managing SharePoint properly can be quite a challenge.

Then what do you need?
When you are implementing or maintaining SharePoint in a proper way, you will need various kinds of skills. Most of the times these skills are not found in one person and therefore a team needs to be created.

The required skills are:

1. Server - Hardware and operating system
   This is the most common discipline and the knowledge that is the most commonly available. Just like with other products, basic server management is required. This includes server patching, monitoring, backup/restore, antivirus management, troubleshooting, etc.


2. Database - SQL server
   SharePoint is build on SQL databases. Without proper administration, these databases potentially can cause issues. However SharePoint databases cannot be compared to regular SQL database. They are very sensitive on actions you can and cannot do with them. Microsoft has released guidance (whitepaper and KB articles) for database administrators on how to manage SharePoint SQL databases.


3. Technical SharePoint
   SharePoint Technical Application Management (TAM) is implementation and management of the infrastructure side of SharePoint. The full SharePoint configuration is the responsibility of TAM, therefore they are the only ones that are allowed to change that configuration. All TAM activities are done by logging onto the server or via the Central Administration. Most common TAM activities are: Application monitoring, troubleshooting application issues, application backup/restore, deploying SharePoint solutions, configuring SharePoint, creating web applications, SharePoint antivirus, etc.


4. Functional SharePoint
   SharePoint Functional Application Management (FAM) is implementation and management of SharePoint from an end-user perspective. Determine which functionalities the user needs, how the logical structure is going to look like and how certain SharePoint components need to be configured. Tasks of FAM would be: Assisting end-users, setting up sites, site structure, content types, determining the desired configuration of SharePoint components like search/user profiles, etc. In an ideal world do these activities not require any access to the SharePoint servers directly. Everything can be done via a web browser.


5. SharePoint Custom Development
   SharePoint is a very extendible platform. If the default out-of-the-box functionalities are not sufficient for end-users, extra functionality can be custom developed. All customizations are build using the .NET Framework, however pure .NET developers are not automatically SharePoint developers. SharePoint has its own set of development rules and best practices. SharePoint developers use Visual Studio to develop their custom code and package that in a SharePoint solution package. This package is then delivered to TAM, who are going to deploy this to the environment.

The technical and functional application management skills can be a grey area, as they can have some overlap. An example is the creation of Managed Properties:

• Specifying managed properties is done by FAM, creating and configuring the managed properties is done by TAM.
• Search management is the full responsibility of FAM

Each of the above skills can be implemented as a dedicated person(s), but also a combination of an SharePoint Technical guy (Skills: TAM/FAM) and a SharePoint Developer (Skills: FAM/Development). This totally depends on your organization. In a large organization, a split might be a good option to have a clear separation of duties.

The team that implements or administers SharePoint must have at least the first four skills available. The skill “SharePoint Development” is very useful (creating visual design, creating tools, etc), but not required.