SharePoint content deployment woes

A little Google searching for issues related to MOSS content deployment will quickly reveal this as a buggy (to be kind) SharePoint feature. I personally have had a lot of frustration trying to use it. The good news is that the Infrastructure Update released in July 2008 has solved many of the content deployment problems I experienced. Though it is still not without issues, content deployment will now at least copy the stuff from one farm to another more-or-less reliably. We have found that for new pages or other objects, you may still need to go into the target site afterwards and tweak a few things, so always check the new items on the target site immediately after a content deployment. Updated items, e.g. content changes, don’t seem to have any issues thus far.

Here are the links to the Microsoft KBs for the updates. Note that as MOSS is based on WSS, you’ll need to apply both updates, first for WSS then for MOSS (you will see this in the documentation).

WSS 3.0 (Windows SharePoint Services) Infrastructure Update

MOSS (Microsoft Office SharePoint Services) Infrastructure Update

I was directed to these updates after breaking down and calling Microsoft for help. :) Out of that conversation came a couple of other things:

• You should always create the target site collection with the Collaboration/Blank template. I saw mixed information on this on various blogs; some recommended creating a truly empty site collection using an stsadm command (there is no GUI equivalent). I found after applying the updates the Collaboration/Blank template seemed to work fine, but here is the stsadm command just in case:

  stsadm -o createsite -url http://something.example.com -ownerlogin login -owneremail email

• stsadm -o export and stsadm -o import is equivalent to doing a content deployment from Central Admin. The advantage of stsadm is that it creates fairly detailed yet oddly nebulous logs in good old text files, which can help pinpoint problems a bit easier than wading through Central Admin screens to view errors. Either way, the information appears equivalent to me and I suspect Central Admin just captures the information from the same logs stsadm generates.

Shrinking SQL Server 2005 log files

Note: for the purposes of this article I am assuming a full recovery model (which is the default).

I have occasionally had database transaction logs grow out of control on SQL Server 2005, e.g. 100M of data and 5G of transaction log. (Specifically, SharePoint configuration databases have done this to me a number of times.) This can affect performance and will most certainly affect backups, aside from obviously consuming inordinate amounts of disk space. You might be thinking “don’t autogrow the transaction log”, but that does not really solve the problem, it simply shortens the amount of time before you have to deal with it. :)

A transaction log has entries for each change you make to the database since the last backup. Internally, the transaction log file is divided into sections called virtual log files. When the current virtual log file fills up and a new one is needed, SQL Server 2005 will allocate the virtual log file that is closest to the beginning of the physical file(s). Under normal circumstances, following a database or transaction log backup, most of the virtual log files will be considered inactive, especially those at the end of the transaction log file. In such cases, if you tell SQL Server to shrink the files you get most of the unused disk space freed. What sometimes happens, though, is that a transaction log entry is still active in a virtual log file closer to the end of the physical file. In such cases, you may only see a small amount of file space in use because there are only one or a few virtual log files in use, but because of the location of the virtual log file within the physical file you cannot shrink the physical file.

To resolve this, first open SQL Server Management Studio to your database instance, and under Management open the Activity monitor. Look at the applications holding locks and shut them down or otherwise prevent them from maintaining a connection so that you have nothing actively using the database but your own login. Then open a new query and execute the following statements, one at a time.

BACKUP LOG database_name TO DISK = ‘X:\some\backup\folder\database.bak‘
DBCC SHRINKFILE (logical_database_log_name, 10) WITH NO_INFOMSGS

If you do that and the file does not shrink, or does not shrink very much, run the statements again; you may want a new backup filename. For some odd reason, it sometimes takes two runs to get a result. You read that right; even Microsoft’s own knowledgebase says to do the same (article 907511).

Another approach that has sometimes worked for me when the above does not:

• Assign a second log file
• Migrate all of the log to the 2nd log file
• Shrink the transaction log files
• Migrate all of the 2nd log back to the first
• Remove the second log

You can do all of this through SQL Server Management Studio.

Update: Please see my article Shrinking SQL Server 2005 log files – part deux for yet another approach.

Also, if you are not aware of it, a good practice is to create a maintenance plan that backs up the transaction logs on a periodic basis. I usually set up daily maintenance plans that backup the transaction logs, shrink the files, do index rebuilds and update statistics, then schedule these to run at a time least likely to interfere with anything but be done before users start their day.

How to copy an assembly from the GAC

The Windows Global Assembly Cache (GAC) is where our developers have been putting shared components for SharePoint web applications. It is a rather vague and somewhat virtual place on the hard drive, usually thought to be located at %windir%\assembly, which is somewhat true. Read on. :)

If you want to copy a file to it, you have to use Windows Explorer and drag-and-drop it into %windir%\assembly. Oddly enough, however, you can’t drag-and-drop or cut-and-paste an assembly out of the GAC in Windows Explorer. If you drop to a command line and cd %windir%\assembly then do a dir, you will not see the list of assemblies you see in Windows Explorer. Instead there are a series of folders corresponding to different assembly types, and folder inside those corresponding to different assemblies and versions thereof. So how do you get something out of the GAC anyway?

If your assembly is named mycode, drop to a command line and cd %windir%\assembly. Now do a search for it with dir mycode* /s/b/p. The result should include a line showing your file with the full path. Now you can use a regular old copy command to copy it somewhere else.

This is most certainly not the full story on the GAC, but hopefully it is enough to enable you to figure it out for your particular situation.

Unblock a nonstandard port in Firefox3

At work yesterday, I was configuring a proxy server for a new company web site. For reasons beyond my control, it is running on port 87 instead of port 80, so the URL looks like http://somewhere.example.com:87/. When you try and load the site in Firefox 3, you get this friendly message:

If you can’t see the screenshot, it says: “This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.” They then offer you the utterly useless Retry button. What is going to change when you click Retry? Instead, there ought to be a way that lets you say “I really do understand that, let me do this anyway”. But there is nothing availabe here or in Tools->Options that lets you work around this behavior. Fortunately, there is a solution in about:config.

This is a special “page” built in to Firefox; enter about:config in the address bar. If you’ve never been here before, you will get a warning; you may want to uncheck the Show this warning next time before you click I’ll be careful, I promise!! button. Now right-click anywhere in the lower portion of the resulting page and select New and then String from the context menu. The name you need to enter is network.security.ports.banned.override, and the value is the port(s) you want to open. If you have more than one, enter them as a comma-separated list. That’s it, no need to restart your browser or do anything else, it should just work now.

Apparently, port 87 has had security exploits in the past, so the Mozilla folks really are trying to protect us. And also from what I read, this same restriction was in Firefox 2 and perhaps earlier versions. Since I no longer have FF2 available on any of my computers, I cannot confirm that. Mozilla developers: can’t we put things like this in some kind of GUI option so we can find stuff without endless Google searching? Thanks.

Application pools and Windows processes

IIS6 uses application pools, where a server process named w3wp.exe services requests for a collection of web sites. Which sites are in which application pool is set as a site property. You can determine easily enough which sites are in each pool from IIS Manager, but what if you need to know which Windows process an application pool is running under? Hint: the processes are all named w3wp.exe. :)

Fear not young padawan, there is a handy little script included that will tell you just that. Drop to the command line and enter cscript %windir%\system32\iisapp.vbs (although you may be able to just enter iisapp.vbs depending on server configuration). So for example iisapp.vbs | sort would give you output like this:

W3WP.exe PID: 1088   AppPoolId: ASP2C-AppPool
W3WP.exe PID: 1356   AppPoolId: ASP1C-AppPool
W3WP.exe PID: 1800   AppPoolId: ASP2A-AppPool
W3WP.exe PID: 2356   AppPoolId: ASP1A-AppPool
W3WP.exe PID: 4148   AppPoolId: ASP1-CCApp-AppPool
W3WP.exe PID: 4484   AppPoolId: ASP1-Jobs-AppPool
W3WP.exe PID: 4820   AppPoolId: ASP1-Purchased-AppPool
W3WP.exe PID: 5020   AppPoolId: ASP2B-AppPool
W3WP.exe PID: 5964   AppPoolId: ASP1B-AppPool

You can see the Windows PIDs for each process using the command-line utility tasklist, or customize the Windows Task Manager to display the PID. For example, tasklist | find “w3wp.exe” | sort will yield something that looks like this:

w3wp.exe                      1088 Console                    0    121,956 K
w3wp.exe                      1356 Console                    0    160,040 K
w3wp.exe                      1800 Console                    0    170,408 K
w3wp.exe                      2356 Console                    0     53,264 K
w3wp.exe                      4148 Console                    0     38,592 K
w3wp.exe                      4484 Console                    0    119,088 K
w3wp.exe                      4820 Console                    0     18,380 K
w3wp.exe                      5020 Console                    0     13,604 K
w3wp.exe                      5964 Console                    0    138,344 K

This can come in particularly handy when you have a process out of control and need to know which application pool is in trouble.