Setting up HTTP Compression For SharePoint

Setting up HTTP Compression For Your SharePoint Portal

HTTP compression is one of the neatest features of ISA server that can help to streamline your portal by reducing filesizes. HTTP compression is a fairly simple technology whose main goal is shrinking data packets using intelligent process whereby data which is disused can be handled more efficiently for your SharePoint portal. This setting is tied onto your SharePoint web listener, during the setup of the web listener, (however can be for all traffic which passes through ISA Server, however it is best to place it listener by listener to ensure granular control over your SharePoint environment), which has to be setup before using any of the HTTP compression mechanisms provided by ISA server. HTTP compression, although can be on an individual listener basis, is also a global policy setting. SharePoint data, although massaged and manipulated through a variety of processes, is still served in a rather common format, and therefore can implement industry standard compressions algorithms, such as the GZIP and Deflate compression mechanisms. Since these types of compressions are built into Windows Server 2003, it makes sense to use these with the ISA architecture. These compression types are also common within most users where SharePoint is used, such as IE 6 and IE5. Although cross-browser support is becoming more common with SharePoint, these are still the most supported, and conventional browsers.
The compression process is fairly simple, and is not much different than a packet hand shaking negotiation between a web client and a web server. A client will request a compressed packet of information from the server from a HTTP 1.1 compatibility browser which supports compression. These packets are compressed using the GZIP and Deflate compression mechanisms. The web server will flag back whether it currently supports this compression, if not the uncompressed content is served under speeds not optimal to bandwidth.
Step 1 — Open the ISA Administration Interfce
Firstly, you must directly interact with the ISA server by logging onto the ISA Server machine either directly, through MSTSC, RDC, or other remote software such as DameWare, Tilovi, or others.
Start -> All Programs -> Microsoft ISA Server -> ISA Server Management
Step 2 Enter Into The ISA General Configuration Screen
With the ISA main server window:
Select your ISA server -> Select Configuration -> Select General
Step 3 Setup Global HTTP Compression Policy Settings
Since setting up HTTP compression is a global policy change within ISA Server, although can be setup on a listener by listener basis for more granular control, we have to enter into the Global Settings of the ISA server.
Within this pane:
Define HTTP Compression Preferences -> Enable HTTP compression

Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *
Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager 
There are certain caveats that exist when using Microsoft Data Protection Manager within your SharePoint environment that have to be taken into consideration when planning your deployment and disaster recovery strategy. These caveats are very important when considering the impact that they might have on your enterprise environment and disaster recovery.
The Largest Caveat
The largest caveat that exists with a marriage of DPM and SharePoint is support for SQL backups (minus using the backup feature to export and flat file exportation) is not currently supported. This feature is planned to be built in the second half of 2007. 
Hardware Requirements for Microsoft Data Protection Manager
Firstly, you have to look at the actual server itself that you are using as your DPM environment. Running DPM requires using Windows Server 2003 with at the very least SP1 applied, and because you will require two volumes for DPM to function correctly you will need to have two different hardrives.  If you attempt to install DPM on a server with only one harddrive, you will get an exception thrown during the setup dialog. You can optionally add this volume at a later date. The reason that there are two harddrives required is the first will be the OS and relevant DPM program files, and the second will be used for data backups, and nothing else. Putting other program files on the second harddrive could possibly cause the DPM server to crash. Make sure that you also meet over the hardware requirements as well. Allocate at least:
  1. A 2 GHz or faster processor
  2. 2 GB of RAM
  3. 3 times the harddrive space as the estimated protected data
These are over the Microsoft recommendations, however when backing up SharePoint farms it can be a rather resource intensive process and therefore is better to plan over estimations that are more tailored to environments where DPM is mainly used as a file share backup mechanism. As well, SharePoint typically will increase the amount of data stored within its repositories dramatically from initial implementation to full production use by organizational virtual teams, and will only get larger as time progresses and more users adopt to using it. Multiplying your estimates by three is a guess, and the amount of disk space that you use should be on a company by company basis. 
Constantly Changing Data In Exported Backup Files
Remember that similar to SharePoint, Data Protection Manager will keep different revisions of its backups. Content housed within SharePoint is changed extremely frequently, since initial document creation can be housed there through an arbitrary amount of changes with an arbitrary amount parties involved. This can be from a single to a triple digit number depending on the nature of the documentation or object. One must plan accordingly with this in mind. Although DPM will only keep revision of the changes, it still can be a large amount when considering the environment we are tailoring DPM for is SharePoint. 
Ensuring Server Compliance Requirements for Data Protection Manager
Secondly, you have to look at the servers that you have available to assimilate into your DPM environment. Within a SharePoint environment, it is fairly atypical to have any other servers other than Windows Server 2003 running, however with some networks there are often other versions of servers such as Windows Server 2000. If you are using a Windows 2000 machine for your data storage, you should firstly install Service Pack 4. If you have other breeds of servers within your environment such as Unix and Linux, these servers are obviously not supported as data stored for DPM as well, as well, you can’t deploy agents to these servers since they won’t be compatible with the executables.
For Fresh Windows Server 2003 Installations 
Once you have Windows 2003 installed, it will bring up an .hta file which will allow you to configure server roles. Role implementation can also be launched by selecting the manage server roles selection out of the program files menu, or can be manually configured using the add/remove program dialog. You can configure the server with any role you choose besides a domain controller. Since the server will be querying other servers within the environment for disk-to-disk backups, it must be a member of the domain that your SharePoint server and SQL cluster reside on. It is not wise to put other software on this server as well, try to keep it as built down as possible so as not to interfere with other DPM processes.
Say No to Encryption with DPM
With SharePoint, the files that we are mostly concerned with protecting will be the exported SQL backup files and SharePoint file stores. There are some file types that are impossible for DPM to backup however, most notably those that are already encrypted, such as documents encrypted with PGP or other relevant encryption engines. When doing system restores of your SharePoint servers, there are other assets that will not stored within the backup, such as:
  • Paging Files
  • The Recycle Bin
  • Volume Information Folder
With SharePoint, there is typically not an end-to-end encryption solution in place because storing encrypted document within SharePoint repositories will confuse the gatherer and searching since it can’t correctly flag the data within the document. An end-to-end encryption solution for SharePoint that carries the encryption cipher is a piece of software currently being developed at ARB Security Solutions.
With the default package of DPM, there are the possibilities of using three different agents, for three different servers, purchasing more agents is relatively inexpensive if you need to protect more assets within your environment.

Creating Certificates With Dual San Attributes

For organizations that have certain security standards, it is customary that the common name on certificates must match the host name of the machine. Furthermore, wildcard certificates are generally unacceptable because of the broad reach that such a certificate implementation could have.

The solution that most organizations will take in light of these considerations is to use a subject alternative name (SAN) attribute on their certificate in order to avoid the ugly certificate mismatch screen that appears in IE7. In IE6 it was an issue because of the homely NT login box that appeared, however this user experience is amplified  in IE7 since the certificate mismatch error will consume an entire page and is therefore not the most attractive experience for users. What a SAN attribute basically accomplishes is the allowance of multiple identities to be bound as the subject on a certificate, whether it is something like a URL, IP, etc. for the certificate request attribute, so that the mismatch never occurs.

So far, this sounds like a pretty good solution for people whose CN must match the hostname of the SharePoint machine. But, if you dig a little deeper into the request architecture for a default Windows Server 2003 instance you will see that natively it is not possible to submit a certificate request where subject alternative names are identified. This of course is a large problem.

The solution is pretty straight forward though, and involves a combination of creating a new certificate request .inf along with a combination of command lines that are run both on the requesting machine and the issuing CA box.

Step 1 – Create a New Certificate Request .inf file

The first step is to create a sharepointcertreq.inf file that will act as an parameter for certificate creation input. This can just be done in your favorite text editor, notepad suffices just fine. Within the .inf file, place the following content:

Subject = “CN=sharepointhostname”
KeySpec = 1
KeyLength = 1024
Exportable = FALSE
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

Step 2 – Create The New Certificate Request 

Using this .inf file, you can pass it in as a parameter to create a certificate request using the certreq tool. This is done on your SharePoint machine that you desire the certificate for. If you are having trouble finding the certreq tool, you might not have it installed on the server. The certreq tools is a part of the  Windows Server 2003 Administration Tools Pack, which you can download from here:

Windows Server 2003 Administration Tools Pack

which will include certreq.exe. Once you have located the executable, submit the following parameters with it:

certreq -new c:\sharepointcertreq.inf c:\sharepointservercert.req

As a side note, this may take a few moments to execute, mainly depending on the size of the key that is specified in the sharepointcertreq.inf file.

Step 3 – Change Some Registry Attributes

Step 3 occurs on the issuing CA machine, so switch to that machine.

Using the certutil -setreg method is nice because you can directly avoid using regedit and navigating through its innards to the appropriate attributes and flags. Issue the following command to support subject alternative names:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Step 4 – Restart Certificate Services

Once you have gotten this far with the changes, it is time to restart certificate services so that the changes take effect. This is best done by creating a small reusable .bat file, since you might be doing certificate configuration a fair amount if you are heavily tailoring the MCS implementation. Like the previous step, this happens on the issuing CA.

Create the following in a CertficateRestart.bat file:

@echo off
REM – File: CertficateRestart.bat
REM – Description: Restart’s Certificate Services
REM – Author: Adam Buenz
echo Restarting Certificate Services…
echo ======================================================
net stop “certificate services”
net start “certificate services”
echo ======================================================
echo Certificate Services Has Been Successfully Restarted

Run the .bat file in order to restart certificate services, which should display “Certificate Services Has Been Successfully Restarted” when it is complete.

Step 5 – Submit the certificate request

With the request file that you created previously, you now have to issue the certificate request. Place the sharepointservercert.req file that you previously created on some sort of accessible medium from the issuing CA machine, best stored on the actual disk somewhere. Following, run the below command in order to submit the certificate request with the relevant SAN attributes:

certreq -q -attrib “SAN:DNS=mysharepointserverSAN” -submit sharepointservercert.req

Once this is complete, your certificate request will go through with the relevant SAN attributes.