Alexander’s Blog

When Federal Trade Commission (FTC) came out with the Do Not Call list idea, everyone loved it. Okay, may be not everyone. I am sure the telemarketers didn’t like the fact that they can’t pick up the phone and start calling anyone they want. But I bet they like it when they themselves don’t receive these uninvited calls. The Do Not Call list is by far one of the most popular successes FTC ever had. Now FTC wants voluntary ‘Do Not Track’ for the Web. The details are posted on the FTC site in this 122-page PDF file. The document was posted on December 1, 2010 and is essentially a Do Not Call list for online behavioral advertising.

Just three days ago on January 24, 2011, Mozilla and Google announced their browser Do Not Track features. You can read more about their approach here. There are pros and cons to the way different companies will implement their features. For example, adding a Do Not Track HTTP header in the browser like Mozilla’s plan for the Firefox browser seems to have an advantage in the sense that even if the user clears the browser cache, the opt-out setting will remain in place. If the feature is implemented as opt-out cookies or an opt-out registry, the results will be different and the setting may be lost. Once the dust settles we will know exactly how different browsers will end up implementing this feature. Frankly, at this point it’s too early and as some wise guy/gal once said, the proof is going to be in the pudding.

Microsoft has already announced in the first week of December that it would add a new Tracking Protection feature to Internet Explorer (IE) 9. This feature is expected to show up in IE9′s release candidate (RC) version sometime in Q1 2011. This is good news because according to some reports Microsoft removed similar features from IE8 because of the pressure from online advertisers.

I was migrating content for a client using the MOSS 2007 built-in Content Deployment functionality. The deployment failed after about an hour or so with the following error.

Content deployment job ‘Migrate All Sites’ failed. The exception thrown was ‘System.IO.IOException’ : ‘There is not enough space on the disk. ‘

I received similar error when I tried to use other tools, such as STSADM. Although the entire content was less than the amount of available disk space on both the source and the destination servers, it was obvious to me that SharePoint is doing something in the background that I don’t understand. Perhaps it is calculating the disk space in a manner that is more complicated and ends up using more disk space than I am expecting. Well, after a little research I stumbled upon Matt Takhar’s blog in which he explained how SharePoint figures out how much disk space is required to migrate the content. According to Matt, this is how the disk space is calculated in MOSS 2007 environment.

Content Migration Process

There are two places on the source server and two places on the destination server where the temporary files are created during the content migration. Essentially, the content migration process takes place in four different steps and each of these four steps require disk space.

1. Source Server Timer Service Temp Area

On the source server the Timer Service uses a temporary area to hold the database in the USERPROFILE temp storage area. For example, if the Timer Service is running under a service account called SPADMIN, the location will be C:\Documents and Settings\SPADMIN\Local Settings\Temp. NOTE: The Local Settings is a hidden folder so make sure that you unhide the hidden folders in Windows Explorer.

If the Timer Service is running under the Local System then the temp folder points to the system TEMP and TMP folders that are defined in your Environment Variables. By default, they point to C:\Windows\Temp.

2. Source Server Central Administration Temp Area

After the Timer Service holds all the data in it’s own temp area, it extracts it to CAB files and stores it in the storage area that is specified in the Central Administration. The exact location is Central Administration -> Operations Tab, Content Deployment -> Content deployment settings -> Temporary Files path. The default location is C:\WINDOWS\TEMP\ContentDeployment.

3. Destination Server Central Administration Temp Area

Next, the files are moved the temp storage area specified in the Central Administration temp area. The exact location is Central Administration -> Operations Tab, Content Deployment -> Content deployment settings -> Temporary Files path. The default location is C:\WINDOWS\TEMP\ContentDeployment.

4. Destination Server Timer Service Temp Area In the final step, the Timer Service on the destination server takes the CAB files and extract the contents to its temp location. From there it loads it into the database on the destination server.

Moral of the Story

So the bottom line is that you need to ensure that at minimum you have two to three times the disk space of the size of the content that you are migrating available on both the source and destination servers. If your content is 20GB then make sure that at minimum you have 40GB-60GB available on the source server and at least 40GB-60GB on the destination server. Because the content migration process can take anywhere from 20GB-40GB, depending on compression and other factors, you need more than 40GB because there are other activities on the server that require disk space, such as system, pagefile, temporary data written by applications, logged on user’s profile activity, etc. If the migration is successful you can verify that the CAB files exist in the Temp\ContentDeployment folder.

Whether the migration fails or it is successful, I like to delete the content in the Temp folder so it is not wasting disk space. Here’s a sample of what the CAB files look like in the ContentDeployment folder after the migration on the destination server.

You can force the content deployment job to clear its cache. You can use the STSADM utility to clear the cache on the source server by using the following command.

stsadm -o editcontentdeploymentpath -pathname “ ” -keeptemporaryfiles Never -enablecompression yes

Although by default Central Administration will run on the first Microsoft Office SharePoint Server (MOSS) 2007, you may be interested in running the Central Administration Web site on multiple SharePoint servers within your farm. If for some reason you are unable to connect to the Central Administration Web site on one server you can use the other server to manage your SharePoint server farm. When you install SharePoint on the second server you will have the option to join an existing farm. You will also have an Advanced button where you can select the second server to run Central Administration Web site. The default option on the second sever is to not host the Central Administration Web Application. However, you can change it to run the Central Administration Web site by selecting the radio button Use this machine to host the web site, as shown below.

If you add a second server to the farm as an application server and run the Central Administration site on that server you will notice that it will default to the first server. Let me explain. Let’s say you have two servers, SERVER1 and SERVER2, both running the Central Administration Web site. In your browser you type the URL for SERVER1, e.g. http://SERVER1:5678 and are able to connect to the Central Administration Web site. Then you type the URL http://SERVER2:5678 and notice that you are redirected to SERVER1. What happened? Well, the Public URL for the zone in the default configuration points URLs for both servers to SERVER1, while the Internal URL is pointing correctly to each server. You can verify this in your Alternate Access Mapping (AAM) by going to Central Administration -> Operations tab -> Global Configuration -> Alternate access mappings. Here’s what your AAM might look like.

What you need to do is edit the Public URL for SERVER2.

1. Click the Edit Public URLs link.

2. In the Alternate Access Mapping Collection box select Change Alternate Access Mapping Collection from the drop-down box.

3. Select Central Administration.

4. The default URL is http://server1:5678. In the Intranet box add http://server2:5678. Your screen should look like this.

5. Your AAM screen will now show that the Internal and Public URLs for each server are properly pointing to SERVER1 and SERVER2.

You will no longer be redirected to SERVER1 when you try and access the Central Administration Web site on SERVER2.

Microsoft has posted a comprehensive list of Hyper-V updates for Windows Server 2008 R2 that you should check it out if you work with Hyper-V.

The posted table shows the list of software updates and hotfixes for Hyper-V in Windows Server 2008 R2. Updates that are available on Windows Update are indicated, as well as the download location for those that are available at the Microsoft Download Center. These updates and hotfixes can help avoid some known issues and may save you a support call.

Keep in mind that some updates are required only under certain circumstances, as noted in the table provided by Microsoft.