On the failing server open Server Manager, and under Roles select Application server. You will most probably find quite a lot of DCOM errors. Open one of those errors to see for which user and for which service the authentication is failing. In the open window copy the GUID of the failing service. It will help you identify the service.

Next open registry editor and select the root node. In Edit menu select Find, paste the GUID and click Find next.

You can find the service name in one of the registry’s values (as seen on the screenshot below, in my case it was IIS WAMREG).

Leave the registry editor open (you might still need it).

Next in Start menu under Administrative tools click Component Services. Expand the Computers node and My Computer. Select DCOM Confing. Now locate the service you identified in your registry, right click it and select Properties.

In the open dialog select Security tab and in the Launch and activation permissions group click the Edit button.

If you have this entire tab grayed out, you need to do the following (outlined in the gray, otherwise skip the gray part below):

In registry editor (which I hope you still have open), right click the node you found and select Permissions Click Advanced and select the Owner tab. Change the owner to the account you’re logged on or to the administrators group (which I presume your account is in) Click Apply and in the permissions dialog also give same user/group full control Now you should close and reopen Component services and find the DCOM service.

In the permissions dialog for the service grant the failing user (or group the account is in) Local Launch and Local Activation permissions. And in case the event log says it is failing remote launch, grant the user remote launch and service also.

Confirm all the changes and close registry editor and Component services window.

Even though at some point when I’d managed to logged in and see my desktop it was impossible to start anything service-based (IIS, SharePoint, Internet Explorer,…)

What did the trick for me? Couple of things, not sure which is THE fix, and I’m adding couple more that I’ve found searching the Web.

1. Reboot into safe mode after applying Windows Updates. This avoids any driver/service conflict issue. After successfully rebooted in safe mode, restart to normal boot.

2. Delete temporary files (to find them, open a "Run" window, type %temp% and press Enter.). This removes the chance of having some legacy corrupt update process file.

3. Check disk space on your system drive – no need for explanation there. Patches can be quite space consuming.

4. If you have IIS (if you have SharePoint, then you do), make a small registry fix to enforce service startup dependancy. Detailed instructions here: http://support.microsoft.com/kb/2004121.

Hopefully one of those "fixes" will work also for you if you’re facing the same problem.

1. You’ve created a web application and you’re sure that credentials are right, but you’re unable to login to the site collection in that web application.

2. Search index log returns strange errors about not finding the web application or access denied.

Then the solution is in the following article:

http://support.microsoft.com/kb/896861 

This did the trick for me:

1. Start regedit
2. Open key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0
3. Create a new multi-string value called "BackConnectionHostNames"
4. Type web application’s host name(s) in the Value Data box.

Save and close regedit. Then using Services under Administrative tools restart the IIS Admin service

Straight to the point:

stsadm for MOSS 2007
http://technet.microsoft.com/en-us/office/sharepointserver/cc948709.aspx

stsadm for WSS
http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd418924.aspx

1. How to limit that the person is not selected and/or added as a member of the site collection (because of licencing issues)
2. How to stop MOSS from importing entire AD domain or forest. If you’re stuck with 100 users from 1000 to enter information manually can be a pain.

The solution can be that SharePoint will not recognize other domains/forests than the ones specified and limit the people from those forests to only certain groups.

Here’s what I did. Let’s say we have an AD domain called contosio.local. In this domain We’ve created OU called AccessGroups and in this OU we’ve created a security group called SharePoint. We want to do this for the site http://moss

1. To limit People picker to certain group in AD domain
a. limit the peoplepicker property only to specified domain by running the following command
stsadm –o setproperty –pn "peoplepicker-searchadforests” –pv “domain:contosio.local,contosioadministrator,adminPassword” –url http://moss

Note in the example above you have to enter the account with the right to read from AD and its password. If you want to limit the access to multiple AD domains, separate the values in pv with semicolon.

b. limit the peoplepicker property to custom LDAP filter by running the following command:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter –pv “(memberOf=CN=SharePoint,OU=AccessGroups,DC=contosio,DC=local)” –url http://moss

Now you’ll be able to add people only from the domain contosio.local – group SharePoint. Don’t forget to add users to security group.

2. To limit profile import only to that same AD group (MOSS ONLY)
a. Open SharePoint Central Administration
b. Open Shared Services Administration
c. Click User Profiles and Properties
d. Click View Import Connections
e. Edit the domain connection for the domain (if you don’t have one yet, you’ll have to create it manually)
f. Change the default value of the field  User filter from (&(objectCategory=Person)(objectClass=User)) to
(&(objectCategory=Person)(objectClass=User)(memberOf=CN=SharePoint,OU=AccessGroups,DC=contosio,DC=local))

Like that you now control from AD who can access SharePoint and who’s profiles get imported.

After searching for a while, I’ve found the solution. Looks like a bug that is fixed with February update, but you have to fix the existing bugs manually.

You can find the solution on Social TechNet. Using Visual Studio create a console application and copy-paste the code published there. I’ve made slight modification to the code, because I needed to have this fix in a subsite:

Old code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Xml;

namespace CA_TestingHotfix
{
    class Program
    {
        static void Main(string[] args)
        {
            FixField(args);
        }

        static void FixField(string[] args)
        {
            string RenderXMLPattenAttribute = "RenderXMLUsingPattern";

            //Console.WriteLine("Please enter the URL of the site: (Press enter after typing):");
            string weburl = args[0];

            //Console.WriteLine("Please enter the Document Library Name: (Press enter after typing):");
            string listName = args[1];
            SPSite site = new SPSite(weburl);
            SPWeb web = site.OpenWeb();
            SPList list = web.Lists[listName];

…

New code (changes marked with bold)

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Xml;

namespace CA_TestingHotfix
{
    class Program
    {
        static void Main(string[] args)
        {
            FixField(args);
        }

        static void FixField(string[] args)
        {
            string RenderXMLPattenAttribute = "RenderXMLUsingPattern";

            //Console.WriteLine("Please enter the URL of the site: (Press enter after typing):");
            string weburl = args[0];
            string subwebUrl = args[1];

            //Console.WriteLine("Please enter the Document Library Name: (Press enter after typing):");
            string listName = args[2];
            SPSite site = new SPSite(weburl);
            SPWeb web = site.OpenWeb(subwebUrl);
            SPList list = web.Lists[listName];

After you have the code ready, compile the program, put it on the server and run the command

[programName].exe [http://site_coll_url] [subweburl] [document_library_name]

If you need to run it for example on the top level web see the example below

fixDocLib.exe –url http://testSite:8080 / “Shared Documents”

With a bit of research into Lookup Field Schema XML I’ve discovered that the LookupList and WebID properties (GUIDS) were wrong. Using SharePoint Manager I could correct the WebID but not the LookupList.

Fortunately after a short period of googling around I’ve discovered this post:

Reattaching LookupList Property to a new List

and that worked like a charm! All the values magically reappeared and lookup dropdowns are back in action.

stsadm -o updatealerttemplates -url http://[portalnamehere] -filename "C:Program filescommon filesMicrosoft sharedweb server extensions12templateXMLalerttemplates.xml"

This fixed my corrupt links and even restored the nice look of the email.

• Page cannot be found error in Internet Explorer when trying to upload to MOSS document library through “Upload” button
• Document not displaying in document library after uploading with “Upload multiple files” button even though the upload went to 100%
• Windows delayed write failed when trying to upload document through Explorer view. After the error the file appears in document library, but it has a file size 0.

The error is not in SharePoint, the error is in IIS7 which limits the upload to 28 MB. To remove this limitation I’ve followed instructions from the KB article:

Error message when you try to upload a large file to a document library on a Windows SharePoint Services 3.0 site: “Request timed out”

Just in case: this did the trick: add the following lines at the end of your web’ application’s web.config file – just before the </configuration> closing tag:

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="2147483648"/>
    </requestFiltering>
   </security>
</system.webServer>

If we take a look at explanation of -cabsize switch when running the command, we can see the following description: [-cabsize <integer from 1-1024 megabytes> (default: 25)]. Looks like 1024 isn’t included. so if you wish to have the backup in chunks larger than 25 MB, use the

-cabsize 1023 switch.

And that does the trick.