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.

Update: If you use Microsoft Office 2010, you have to use other fix:

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

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.

(Below also message in Slovene for my Slovene-SharePoint-using-friends)

Then you’re missing something. The same as me. The support article from Microsoft (located here) explains that we need to do one of the following:

1. Don’t use 64-bit Office 2010 or
2. if you have to use the 64-bit version, download and install the 2007 Office System Driver: Data Connectivity Components

This goes for SharePoint 3.0/2007 and 4.0/2010

Reasons (besides Windows7 and Vista):

1. WebClient service not started
2. SharePoint domain has dots (.) in the name
3. Your IE is trying to resolve LAN/Proxy settings

Solution

Important! Part of solution is also modifying your registry. Please if you’re not sure how to modify registry, get help from an expert. I will not assume any responsibility for possible errors that may result from editing your registry. This solution is not done on server, but on every client that has this kind of trouble.

1. Tell your WebClient Service to where to provide your credentials. By default the WebClient service provides credentials only to sites that don’t have dots in url – presuming they’re in your intranet. Any SharePoint site that has dots in url is presumed in Internet for WebClient. Here’s how:

1. Using registry editor, open the following registry subkey:
   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters
2. Next create new Multi-String Value (menu Edit –> New –> Multi-String Value)
3. Name the value AuthForwardServerList
4. After the key has been created, modify its value (Right click it and select Modify).
5. Enter full URLs of your SharePoint sites (one per line).
6. Save and exit registry editor.
7. If you use Windows Vista, you have to request a special hotfix for this resolution to work.

Detailed instructions and hotfix request available on Microsoft Support site.

2. Start / Restart WebClient Service

1. Open the "Run" prompt (key combination Start+R)
2. Type services.msc and press Enter.
3. Locate WebClient service
4. Make sure your service startup mode is set to automatic (right click it, select "Properties", and under "General" tab select "Automatic" from the "Startup Type" dropdown"
5. Start the service or restart it if it’s already running. (restart in any case for step 1 to take effect).

This part is summed from this link (at the end)

UPDATE: Another reason could be auto-detection of proxy if there is none present.

The way to turn this off is in Internet Explorer:

1. In Tools select Internet options.
2. Select Connections tab
3. click Lan settings button
4. under Automatic configuration clear the Automatically detect settings checkbox.