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.

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.

I recently encountered a DCOM error repeating numerous times in the event logs on a SharePoint server, which eventually led to a resolution I am about to explain. But DCOM errors are certainly not exclusive to SharePoint, and I have personally seen this error occur with a number of applications. The method presented here can be used to try and resolve similar issues regardless of the software involved.

I also need to say that much of this was drawn from a post by Søren Nielsen where he solved a SharePoint DCOM error. If you administer SharePoint, I highly recommend his blog, particularly for more advanced technical topics. He has a knack for tracking down the oddball things that are often found on SharePoint servers. Now, on to the solution to the problem…

The preceeding screenshot is what I was seeing in the event viewer. There are two things to note in this event, besides it being a DCOM error. First, the CLSID is a reference to the software component that generated the error. Second, the description indicates that the user – scrubbed out here - is lacking the “Local Activation” permissions. You can also see a hint as to where you fix the problem – using the “Component Services administrative tool”.

We are first going to search the registry to figure out the name of the software component generating the error. The CLSID is rather lengthy, so I recommend you select the string in the event viewer and press Ctrl-C to copy it to the clipboard. Open the registry editor (Start, Run, and enter regedit). Scroll the left-hand pane all the way to the top and select My Computer, then select Find under the Edit menu. Paste (or type if you must) the CLSID into the Find what textbox, and Keys should be checked under Look at. Click Find Next until the path to the key displayed on the status bar looks like My Computer\HKEY_CLASSES_ROOT\CLSID\yourCLSID and regedit looks something like this:

Take a look at the (Default) value for the name of the component. In some cases like the SharePoint component shown, you may have subkeys. If you do, also take a look at what values are in them. In this case, VersionIndependentProgID was helpful to me as it ultimately contained the name of the component as a prefix to the (Default) value.

We should now have enough information to fix the problem. Click Start, select Run, and enter dcomcnfg to open the Component Services administration snapin. Expand Component Services, then Computer, then My Computer, and finally DCOM Config. On a typical server, you will see many components are installed. Look for one with the name you found in the registry; in my case it was OSearch from the VersionIndependentProgID key as mentioned above. It is critical that you find the right component, otherwise none of the remaining steps are going to fix anything and you may inadvertenly cause other problems, or potentially even open a security hole.

Right-click the component, in my case OSearch, and select Properties, then select the Security tab. The Launch and Activation Permissions is where you fix the problem, so in that groupbox, select Customize if it isn’t already selected then click the Edit button. You should see something like the following:

The user identified in the event needs to be in the list of user names. If not, click Add and use the standard dialogs to add the user to the list. Highlight the user, then ensure that Local Launch and Local Activation are selected, then click OKs until you close all dialogs. That should fix the problem!

It always seems so simple after you know the solution… :)

By default, SharePoint will install the Central Administration web application to run over ordinary unsecured HTTP but on a random IP port. It is generally a Good Idea ™ to run using SSL/HTTPS instead. To do so, there are two things you need to do: install an SSL certificate in IIS, and change the IP port used by SharePoint for the Central Administration site.

Open IIS Manager and get properties on the site labeled SharePoint Central Administration v3. Open the Directory Security tab and click on Server Certificate. What happens next depends on whether you need to create a new certificate or already have one you can use. There is plenty of information you can google for the process of obtaining or installing existing certificates if you don’t know already know how. Complete the wizard as appropriate to your situation, specifiying port 443 if prompted.

With the certificate installed, IIS is able to use HTTPS via port 443, but SharePoint knows nothing about the changes you made in IIS and is still only expecting to communicate over whatever random port was in place. There is a quick stsadm command to fix that:

stsadm -o setadminport -ssl -port 443

Don’t be alarmed if it appears to take a moment. When finished, it should tell you Operation completed successfully. After that, I have found it pays to wait a couple more minutes for SharePoint to finish the changes internally. Then try opening Central Administration, e.g. https://host.example.com/. Your Central Administration page should appear momentarily. Once you have successfully opened Central Administration, return to the site properties, and on the Directory Security tab click Edit… just a little below the Server Certificate button you clicked earlier. Then check Rquire secure channel (SSL), and I recommend you also check Require 128-bit encryption. Click OK, then OK again to close the site properties. You will now only be able to open the Central Administration over SSL.