Harmjan Greving’s Blog

I downloaded the Web.config modification manager for SharePoint written by Vincent Rothwell from:
http://blog.thekid.me.uk/archive/2007/03/24/web-config-modification-manager-for-sharepoint.aspx

It is a nice add-in for the central admin. The tool manages all the web.config modifications that are done with the SPWebConfigModification class.

For our customer I need some more functionality like:
- adding modifications with the type EnsureSection;
- updating the current modifications;
- display the active modifications (the latest modification with the highest sequence);
- fix that the tool also works in complex farm scenario’s:
            SPFarm.Local.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
changed that into:
            oApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
(Because Local.Services can not access the other machines? I read about this somewhere on the internet)

Here you can download my update of the webconfig.aspx. Simply add the file to the following folder:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\ADMIN

This folder contains the application pages for the central admin. You can visit the page easily by visiting the following url: http://CENTRALADMIN:PORT/_admin/webconfig.aspx

Vincent Rothwell has also a version with a Solution installer (by Lars Fastrup) with a Custom Action that adds the file to the Central Administration > Application Management page.

Hope this helps you with controlling the web.config modifications.

On many websites you read about installing FeatureReceiver assembly inside the Global Assembly Cache (GAC) instead of placing the assembly inside you’re web application bin folder. In this post I will explain why it is necessary to use the GAC.

Inside a SharePoint webapplication on site collection level or site level you can activate and deactivate features. If you activate a feature in this context and you’re assembly is located in the web application bin folder everything will be fine. The assembly can be found because you’re inside the context of you’re web application that has the dll (in the bin folder). The .Net framework checks the GAC first, when the assembly cannot be found in the GAC, the local bin folder is checked. So the assembly can be found in this situation.

But when you decide to activate you’re feature from STSADM command or you’re feature will be activated by another site definition feature which contains FeatureActivation dependency, the feature will be activated from within the Central Admin by creating a site collection. In both scenarios the context is different. So the .Net framework checks the GAC first and will find no assembly in the GAC. After the GAC the local bin folder (from stsadm or Central Admin web application) is checked and the assembly cannot be found there. Because the assembly resides in the bin folder of you’re web application.

This is the message you get:
System.IO.FileNotFoundException: Could not load file or assembly '<assembly>' or one of its dependencies. The system cannot find the file specified.

SOLUTION:
Put all you’re FeatureReceiver assemblies in the GAC.

As a SharePoint 2007 developer you have to use the stsadm command line tool to add a solution to the SharePoint solution store. You can do this with the following command:

stsdm -o addsolution -filename <the name of your solution (*.wsp) file>

This simple command takes up to 15 seconds on my development server. So I tried a simple stsadm command without parameters. And this command also takes 15 seconds.

I realised me a situation that the stsadm command was ready in 1 second. So I thought maybe it has something to do with the internet connection. (Because my development server is disconnected from internet)

I started googling and found this: “When you use authenticode signed assemblies in an application, the application needs to go out and check the certificate revocation lists (CRLs) to verify that the signature is still valid the first time it loads up the authenticode signed assembly. If the server, serving your asp.net application, doesn’t have internet access or if the internet connection is slow this can lead to issues where you stall the process during startup or when the assembly in question first loads.”

My experience in a disconnected scenario is that not only the first time the assemblies loads slow. It loads always slow, because the CRLs cannot be found and the network timeout is reached. Behind a firewall or proxy the stsadm commands are 2 times slower! The commands will always take place after the timeout period. So why should we wait for that?! 

For more information read the article:
http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx

SOLUTION:
The solution is to avoid checking the CRLs by adding the following code to the machine.config:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled=“false”/>
    </runtime>
</configuration>

Be sure you have .Net Framework 2.0 SP1 installed. 

For more information about the hotfix visit the following website:
http://support.microsoft.com/default.aspx/kb/936707

If you’re using Windows XP you can’t install this version of Visual Studio 2008 Extensions, because you don’t have Windows SharePoint Services 3.0 installed:

Here I read a solution to let you’re computer act as it has WSS 3.0 installed:
http://blogs.msdn.com/jannemattila/archive/2007/08/16/how-to-install-windows-sharepoint-services-3-0-tools-to-xp-or-vista.aspx

1. Start regedit

2. Add the key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0] 

3. Add the value: “Sharepoint”=”Installed”

After that, download the software and install it:
Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2

When you right click with you’re mouse on the desktop and choose properties, normally you will see something like:

In my situation I had no ScreenSaver tab in that window because someone hide it:

I’ve a solution to make the ScreenSaver tab appear again. This solution works only if you’re the Administrator or if you’ve write access to the registry:

1. Start the program: regedit

2. Find the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system

3. Set NoDispScrSavPage to 0:

For a customer we had to set  up a Microsoft Office SharePoint Server 2007 (MOSS 2007) Multiple Server Farm. The customer uses the Content Management Server (CMS) possibilities of SharePoint 2007 to manage the company’s Internet site.

Before we started setting up the servers and building the farm, web applications and sites we had to consider the company’s network architecture. This consists of an Intranet zone and a perimeter network (also called a DMZ), split into two sections: the Inner DMZ and the Outer DMZ. One of the challenges during the assignment was to keep this setup and all the security properties of the networks intact, and still make it work.

For security reasons the Internet users may not connect to any site on the Intranet directly and also it would not be a good idea to let (internal) Intranet users manage content directly on a webserver in a DMZ. Therefore we set up two farms: one Intranet Farm and one DMZ Farm. Moreso, we split the Internet Farm between a Web Frontend server in the Outer DMZ and the Database and Services (Search, SSP and Central Admin) in the Inner DMZ.  Between the two DMZs resides an ISA server for access security.

The editors work on the website inside the company’s Intranet. Content is synchronized to the Internet (DMZ farm) with Web Content Deployment Content (Paths and Jobs) and all changed and published content is sent to the DMZ every 15 minutes. You can read about Content Deployment in our next post.

So there was ‘just’ one problem. Since the DMZ Farm is a real farm (not a single server setup), it is required to use domain accounts for the service accounts. This automatically means you need a separate AD domain controller inside the DMZ. Sharing the DMZ domain with the intranet domain would be possible too, however the whole purpose of a DMZ  is not to put your authentication at risk. So we needed a separate AD Domain controller just for the service accounts. If that controller is compromised, the internal domain is not affected.

So we ended up with 4 Servers in two Farms for a minimum configuration. From this point on it’s a matter of extending Database, Services and/or Web Frontend Servers. We could start installing the software and configuring them:

Intranet Farm > Database Server

· Windows Server 2003 SE SP1
· Internet Information Services (IIS)
· SQL Server 2005 (installs also the .NET Framework 2.0)

DMZ Farm > Database and Web Server

· Windows Server 2003 SE SP1
· Internet Information Services (IIS)
· SQL Server 2005 (installs also the .NET Framework 2.0)
· .NET Framework 3.0
· Windows Server Support Tools
· MOSS 2007 with SP1 (WSS SP1 and MOSS 2007 SP1 included)
(· MOSS 2007 additional language packs)
· Run the SharePoint Configuration Wizard
(· MOSS 2007 language pack SP1)
(· WSS 3.0 post SP1 hotfix for content deployment [KB950279])

Intranet and DMZ Farm > Web Servers (2 Servers)

· Windows Server 2003 SE SP1
· Internet Information Services (IIS)
· .NET Framework 2.0
· .NET Framework 3.0
· Windows Server Support Tools
· MOSS 2007 with SP1 (WSS SP1 and MOSS 2007 SP1 included)
(· MOSS 2007 additional language packs)
· Run the SharePoint Configuration Wizard
(· MOSS 2007 language pack SP1)
(· WSS 3.0 post SP1 hotfix for content deployment [KB950279])

And also run the windows updates for the Operating System (OS), SQL Server 2005 and the .Net Framework updates etc.

There is one *really* important thing to keep in mind here: always keep all servers in the farm (f.i. all Web Front End Servers) and the software completely identical. So either install service releases on all systems, or onto none at all.

For a developer it’s easy to use a Microsoft Office SharePoint Server 2007 (MOSS 2007) in a Single Server Farm. You’ve to install the following software on a Windows Server that has WSS 3.0 on board:

1. Logon or install a Windows Server 2003 or Windows Server 2008 with an administrator account;
2. Install .Net framework 2.0;
3. Install .Net framework 2.0 SP1;
4. Install .Net framework 3.0;
5. Install SharePoint 2007 - Select the option: ”Single Server Farm installation”;
6. Install WSS 3.0 SP1;
7. Install SharePoint 2007 SP1.

The SharePoint 2007 installation includes SQL Server 2005 Express Edition.

You’re now reading the blog of Harmjan Greving. I am a Software Developer for Atos Origin. On this blog I write about my experiences with Microsoft Technologies. I hope you will find here some usefull information.